Theory
Pieces को साथ काम कराना
आपके पास एक front end और एक back end है, और एक database design है। Integration वहाँ है जहाँ ये, और कोई भी outside services, एक working system में connect होते हैं। यह एक distinct और अक्सर tricky phase है: parts जो अकेले-अकेले काम करते हैं वे फिर भी साथ काम करने में fail हो सकते हैं।
तीन connections matter करते हैं: back end का database से, back end का किसी भी external APIs से (services जो आप खुद build नहीं करते), और front end का back end से। यह lesson इन्हें integrate करना cover करता है, और यह early और carefully करना nasty surprises क्यों avoid करता है। Integration वहाँ है जहाँ parts का एक collection एक actual application बनता है।
Theory
Database और External APIs
Back end आपके database से connect होता है data store और retrieve करने के लिए, आपके ER diagram से structure इस्तेमाल करते हुए। यह core integration है: आपका logic real, persistent data पढ़ते और लिखते हुए।
यह external APIs से भी connect हो सकता है, third-party services जिन्हें आप build करने की बजाय call करते हैं। Examples: एक payment gateway (payments लेने के लिए), एक maps service (locations के लिए), email या SMS services (notifications के लिए), या Firebase (authentication के लिए)। आप इनकी API call करते हैं, और वे service provide करते हैं, आपको complex systems खुद build करने से बचाते हुए।
External APIs powerful हैं, ये आपको capabilities देते हैं जो आप एक semester में कभी build नहीं कर सकते, पर ये एक dependency add करते हैं: आपका system अब उस service पर rely करता है, तो आपको इसके errors handle करने पड़ते हैं (क्या हो अगर यह down है या एक request reject करता है?) और इसकी documentation carefully पढ़नी पड़ती है।
Formula
Early Integrate कीजिए, और Surprises Expect कीजिए
यह hard-won advice है: early और incrementally integrate कीजिए, weeks तक front end और back end को total isolation में build मत कीजिए और सिर्फ़ end में इन्हें connect कीजिए। Integration exactly वहाँ है जहाँ hidden problems surface होते हैं: mismatched data formats, authentication issues, एक external API से unexpected errors, connections जो assumed तरीके से behave नहीं करते।
अगर आप सारी integration last minute के लिए छोड़ते हैं, आप इन problems को तब discover करते हैं जब इन्हें fix करने के लिए कोई time नहीं है। इसके बजाय, parts को जैसे आप build करें connect कीजिए, हर integration point test कीजिए, और errors gracefully handle कीजिए। Parts का अकेले काम करना system के काम करने के same नहीं है; सिर्फ़ integration ही यह prove करता है। इसे early wire कीजिए साथ, और surprises तब आते हैं जब आप अभी भी इन्हें handle कर सकते हैं।
Quiz
आपको अपने project के parts (front end, back end, database, external APIs) सिर्फ़ end में integrate करने की बजाय early और incrementally क्यों integrate करने चाहिए?
- क्योंकि integration हमेशा पहली बार perfectly काम करता है
- क्योंकि integration exactly वहाँ है जहाँ hidden problems surface होते हैं (mismatched formats, auth, errors), तो early connect करना आपको इन्हें find और fix करने का time देता है
- क्योंकि parts को कभी connect होने की ज़रूरत नहीं
- Project को longer बनाने के लिए
Show the answer
क्योंकि integration exactly वहाँ है जहाँ hidden problems surface होते हैं (mismatched formats, auth, errors), तो early connect करना आपको इन्हें find और fix करने का time देता है
आपको early और incrementally integrate करना चाहिए क्योंकि integration exactly वहाँ है जहाँ hidden problems surface होते हैं, mismatched data formats, authentication issues, external services से unexpected errors, connections जो assumed से differently behave करते हैं, और early connect करना आपको deadline से पहले इन्हें find और fix करने का time देता है। Option A wrong और dangerous है: integration शायद ही कभी पहली बार perfectly काम करता है; यही assumption है जिस वजह से इसे end के लिए छोड़ना disasters cause करता है। Option C false है: project का पूरा point यह है कि parts एक working system में connect होते हैं। Option D nonsense है: early integrate करना overall time बचाता है problems को catch करके जब वे छोटे हैं। Parts का अकेले काम करना system के काम करने के जैसा नहीं है; inevitable connection issues को समय पर surface और solve करने के लिए early integrate कीजिए।
Think first
जो Parts अकेले-अकेले काम करते हैं वे Connect होने पर फिर भी क्यों Fail होते हैं?
Front end काम करता है, back end काम करता है, तो इन्हें connect करना इतनी बार नए problems क्यों reveal करता है? फिर tap कीजिए।
Show the answer
क्योंकि जब दो parts separately build होते हैं, हर एक दूसरे के बारे में ASSUMPTIONS के against build होता है, और वे assumptions शायद ही कभी perfectly match करते हैं, तो mismatches, हर part अकेला test होने पर invisible, सिर्फ़ उस point पर appear होते हैं जहाँ वे actually मिलते हैं। सोचिए 'हर part काम करता है' का really क्या मतलब है: front end उस against काम करता है जो यह EXPECT करता है back end भेजे और accept करे; back end उस against काम करता है जो यह EXPECT करता है front end भेजे और उस against जो यह ASSUME करता है database या एक external API कैसे behave करता है। पर ये expectations independently form होती हैं, और छोटे differences creep in करते हैं: front end एक date text की तरह भेजता है पर back end एक number expect करता है; back end एक field एक name से return करता है पर front end कोई और पढ़ता है; API एक authentication token expect करता है जो front end attach नहीं करता; एक external service errors एक format में return करता है जिसे किसी ने anticipate नहीं किया; एक data field database column के allow से longer है। इनमें से कोई भी एक part को ISOLATION में testing करते समय show नहीं होता, क्योंकि isolation में हर side consistently अपने own assumptions इस्तेमाल करता है। ये सिर्फ़ INTEGRATION point पर surface होते हैं, जहाँ एक part का real data और real behaviour दूसरे की expectations से मिलता है, और mismatch कुछ तोड़ देता है। यही वजह है integration famously जहाँ bugs hide होते हैं, और यही वजह है 'यह मेरे part पर काम करता है' 'system काम करता है' के same नहीं है। कुछ genuinely नए concerns भी हैं जो सिर्फ़ parts के BETWEEN exist करते हैं: boundary के across authentication, एक remote call fail होने पर error handling, network issues, data format agreements, timing, इनमें से कोई भी single part अकेला पूरी तरह test नहीं कर सकता। Remedy है EARLY और INCREMENTALLY integrate करना, parts के बीच real interaction को connect और test करना जैसे आप इन्हें build करें, तो ये mismatched assumptions तब expose हों जब ये छोटे हैं और इन्हें reconcile करने का time है, end में इनका एक pile discover करने की बजाय। Integration testing (एक level जो आप अगले में मिलेंगे) exactly इसी के लिए exist करता है। तो parts का connect होने पर fail होना normal और expected है, यह assumptions का reality से मिलना है, जो exactly वजह है आपको connections deliberately integrate और test करना पड़ता है, यह assume करने की बजाय कि ये बस fit हो जाएँगे। Separate parts separate assumptions carry करते हैं; integration वह है जहाँ ये reconcile होते हैं।
Summary
Key takeaways
- Integration separately built parts, front end, back end, database, external APIs, को एक working system में connect करता है।
- Back end database से connect होता है (आपके ER design से) data store और retrieve करने के लिए।
- Back end external APIs से connect हो सकता है, third-party services जिन्हें आप call करते हैं build करने की बजाय (payments, maps, email/SMS, Firebase auth)।
- External APIs वे capabilities देते हैं जो आप खुद build नहीं कर सकते, पर एक dependency add करते हैं, तो इनके errors handle कीजिए और इनके docs पढ़िए।
- Front end API calls के through back end से connect होता है।
- Early और incrementally integrate कीजिए, क्योंकि integration वहाँ है जहाँ hidden problems (mismatched formats, auth, errors) surface होते हैं; early connect करना इन्हें fix करने का time देता है।
- Memory hook: parts को early साथ wire कीजिए और हर connection test कीजिए, parts का अकेले काम करना system के काम करने के जैसा नहीं है।