माइक्रो-फ़्रंटएंड माइग्रेशन की यात्रा करना - भाग 1: डिज़ाइन

आज की तेज़ गति वाली डिजिटल दुनिया में, जहाँ चपलता और मापनीयता महत्वपूर्ण है, व्यवसाय लगातार अपने वेब अनुप्रयोगों के प्रदर्शन और रखरखाव में सुधार के तरीके खोज रहे हैं।

इन लक्ष्यों को प्राप्त करने के लिए एक लोकप्रिय दृष्टिकोण एक अखंड वास्तुकला से एक वितरित (या माइक्रो-फ़्रंटएंड) की ओर पलायन करना है। यह लेख श्रृंखला, "माइक्रो-फ़्रंटएंड माइग्रेशन जर्नी", AWS में मेरे समय के दौरान इस तरह के माइग्रेशन करने के मेरे व्यक्तिगत अनुभव को साझा करती है।

अस्वीकरण : शुरू करने से पहले, यह ध्यान रखना महत्वपूर्ण है कि हालांकि यह लेख मेरे व्यक्तिगत अनुभव को साझा करता है, मैं एडब्ल्यूएस या किसी अन्य संगठन में उपकरण, प्रौद्योगिकियों या विशिष्ट प्रक्रियाओं के किसी भी मालिकाना या आंतरिक विवरण का खुलासा करने में सक्षम नहीं हूं।

मैं कानूनी दायित्वों का सम्मान करने और यह सुनिश्चित करने के लिए प्रतिबद्ध हूं कि यह लेख पूरी तरह से माइक्रो-फ्रंटएंड माइग्रेशन यात्रा में शामिल सामान्य अवधारणाओं और रणनीतियों पर केंद्रित है।

इसका उद्देश्य ऐसी अंतर्दृष्टि और सबक प्रदान करना है जो किसी भी गोपनीय जानकारी का खुलासा किए बिना व्यापक संदर्भ में लागू हो सकते हैं।

प्रवास के लिए प्रेरणा

मैंने मार्टिन फाउलर के ब्लॉग पर लेख से माइक्रो-फ़्रंटएंड के बारे में (मुझे लगता है कि आप में से कई लोगों को) सीखा। इसने फ़्रेमवर्क-अज्ञेयवादी तरीके से माइक्रो-फ़्रंटएंड आर्किटेक्चर की रचना के विभिन्न तरीके प्रस्तुत किए।

जैसे-जैसे मैं इस विषय में गहराई से उतरा, मुझे एहसास हुआ कि हमारी मौजूदा अखंड वास्तुकला हमारी टीम की उत्पादकता के लिए एक महत्वपूर्ण बाधा बन रही थी और हमारे एप्लिकेशन के समग्र प्रदर्शन में बाधा बन रही थी।

उन प्रमुख कारकों में से एक जिसने मुझे माइग्रेशन पर विचार करने के लिए प्रेरित किया, वह था हमारे एप्लिकेशन का बढ़ता बंडल आकार।

2020 की गर्मियों में गहन बंडल विश्लेषण करने के बाद, मुझे पता चला कि 2019 की शुरुआत में इसके शुरुआती लॉन्च के बाद से, बंडल आकार (gzipped) 450KB से 800KB तक बढ़ गया है (यह लगभग 4MB पार्स किया गया है) - मूल आकार से लगभग दोगुना।

हमारी सेवा की सफलता को ध्यान में रखते हुए और इसकी निरंतर वृद्धि की भविष्यवाणी करते हुए, यह स्पष्ट था कि यह प्रवृत्ति जारी रहेगी, जिससे हमारे एप्लिकेशन के प्रदर्शन और रखरखाव पर और प्रभाव पड़ेगा।

जबकि मैं माइक्रो-फ़्रंटएंड की अवधारणा के बारे में उत्साहित था, मैंने यह भी माना कि हमारे सामने आने वाली विशिष्ट चुनौतियों के कारण हम अभी तक उन्हें अपनाने के लिए तैयार नहीं थे:

1. छोटी संगठनात्मक संरचना: मेरे विश्लेषण के समय, हमारा संगठन अपेक्षाकृत छोटा था, और मैं टीम में एकमात्र पूर्णकालिक फ्रंटएंड इंजीनियर था। माइक्रो-फ़्रंटएंड आर्किटेक्चर में स्थानांतरित होने के लिए संगठनात्मक संरचना और परिचालन नींव के संदर्भ में एक महत्वपूर्ण निवेश की आवश्यकता होती है।

   
   

   एक परिपक्व संरचना का होना महत्वपूर्ण था जो वितरित वास्तुकला को प्रभावी ढंग से संभाल सके और विभिन्न फ्रंटएंड घटकों के बीच निर्भरता को प्रतिबिंबित कर सके।

   
   

2. सीमित व्यावसायिक डोमेन: हालाँकि माइक्रो-फ़्रंटएंड को सीमित संदर्भों और व्यावसायिक क्षमताओं के आधार पर विभाजित किया जा सकता है (' माइक्रो-फ़्रंटएंड आर्किटेक्चर में डोमेन-संचालित डिज़ाइन' पोस्ट में और जानें) हमारा मुख्य व्यवसाय डोमेन इतना व्यापक नहीं था कि इसमें पूर्ण वियुग्मन को उचित ठहराया जा सके। एकाधिक माइक्रो-फ्रंटेंड। हालाँकि, एप्लिकेशन के भीतर दृश्यमान सीमाएँ थीं जो एक वितरित आर्किटेक्चर को तराशने और परिवर्तित करने के लिए समझ में आती थीं।

इन कारकों पर विचार करते हुए, मुझे एहसास हुआ कि एक क्रमिक दृष्टिकोण आवश्यक था। माइक्रो-फ़्रंटएंड पर पूर्ण माइग्रेशन के बजाय, मेरा लक्ष्य हमारे एप्लिकेशन के भीतर विशिष्ट क्षेत्रों की पहचान करना था जो वितरित आर्किटेक्चर से लाभान्वित हो सकते हैं।

यह हमें समग्र संगठनात्मक संरचना को बाधित किए बिना या हमारे व्यावसायिक डोमेन की अखंडता से समझौता किए बिना प्रदर्शन और स्केलेबिलिटी संबंधी चिंताओं को संबोधित करने की अनुमति देगा। इससे हमें टीम को विकसित करने और व्यावसायिक दिशाओं का निरीक्षण करने के लिए कुछ समय भी मिलेगा।

कृपया ध्यान दें कि यदि आप केवल mciro-frontend आर्किटेक्चर का उपयोग करके ऐप के प्रदर्शन (बंडल आकार) की समस्या से निपटना चाहते हैं, तो यह सबसे अच्छा विचार नहीं हो सकता है। वितरित मोनोलिथ आर्किटेक्चर के साथ शुरुआत करना बेहतर होगा जो इसके बजाय आलसी लोडिंग (गतिशील आयात) का लाभ उठाएगा।

इसके अलावा, मुझे लगता है कि यह माइक्रो-फ्रंटएंड आर्किटेक्चर की तुलना में बंडल आकार के मुद्दों को अधिक खूबसूरती से संभाल लेगा, यह देखते हुए कि माइक्रो-फ्रंटएंड आर्किटेक्चर में कुछ साझा कोड होने की बहुत संभावना है, जिसे विक्रेता खंडों में अलग नहीं किया जाएगा, और इसे एप्लिकेशन बंडल में बनाया जाएगा ( यह इस तरह के वितरित आर्किटेक्चर की कमियों में से एक है - आपको क्या साझा करना है, कब और कैसे साझा करना है के बीच एक समझौता करना होगा)।

हालाँकि, वितरित मोनोलिथ आर्किटेक्चर माइक्रो-फ़्रंटएंड के समान स्केल नहीं करेगा। जब आपका संगठन तेजी से बढ़ता है, तो आपकी टीम भी उसी गति से बढ़ेगी।

कोड आधार को विभिन्न टीमों द्वारा नियंत्रित स्वामित्व के विभिन्न क्षेत्रों में विभाजित करने की आवश्यक आवश्यकता होगी।

और प्रत्येक टीम को अपने स्वयं के रिलीज़ चक्र की आवश्यकता होगी जो दूसरों से स्वतंत्र हों, प्रत्येक टीम इसकी सराहना करेगी यदि उनका कोड आधार पूरी तरह से उनके डोमेन पर केंद्रित होगा, और तेजी से निर्माण करेगा (कोड अलगाव -> बेहतर रखरखाव / बनाए रखने के लिए कम कोड और निर्माण -> बेहतर परीक्षण योग्यता/बनाए रखने और निष्पादित करने के लिए कम परीक्षण)।

प्रारंभ

नेतृत्व से समर्थन प्राप्त करने के लिए, मैंने एक प्रेरक तकनीकी दृष्टि दस्तावेज़ तैयार किया जिसमें वेब महत्वपूर्ण मेट्रिक्स सहित एक व्यापक प्रदर्शन विश्लेषण शामिल था, और वितरित फ्रंटएंड की ओर प्रवास के विभिन्न चरणों की रूपरेखा तैयार की गई थी।

इस माइग्रेशन के मध्यवर्ती चरणों में से एक एक वितरित मोनोलिथ आर्किटेक्चर स्थापित करना था, जहां कोर सेवा और विजेट्स के बीच एस 3 बाल्टी और सीडीएन जैसे साझा बुनियादी ढांचे का लाभ उठाते हुए कई मॉड्यूल/विजेट्स को आलसी-लोडिंग तकनीकों के माध्यम से अतुल्यकालिक रूप से वितरित किया जा सकता था। .

जैसा कि मैंने अपने पिछले लेख में बताया था, इस प्रकार के दस्तावेज़ का मुख्य विचार भविष्य का वर्णन करना है जैसा कि आप चाहते हैं कि एक बार उद्देश्यों को प्राप्त कर लिया जाए और सबसे बड़ी समस्याएं हल हो जाएं। यह क्रियान्वयन योजना के बारे में नहीं है!

लगभग 1 साल बाद, आख़िरकार मेरी माइक्रो-फ़्रंटएंड माइग्रेशन योजना को क्रियान्वित करने का समय आ गया। एक नए डोमेन में आसन्न विस्तार और हमारे पास एक बड़ी टीम के साथ, हम माइग्रेशन को निष्पादित करने के लिए अच्छी तरह से सुसज्जित थे।

ऐसा लगा जैसे यह एक सुनहरा अवसर है जिसे हम चूकना बर्दाश्त नहीं कर सकते।

आख़िरकार, अखंड वास्तुकला तक ही सीमित रहने का मतलब इसकी सीमाओं से लगातार जूझना होगा।

एक नए डोमेन में विस्तार करने की सीमित समयरेखा एक उत्प्रेरक के रूप में काम करती है, जो हमें छोटी और धीमी पुनरावृत्तियों के बजाय तुरंत एक अधिक स्केलेबल और रखरखाव योग्य वास्तुकला के निर्माण की ओर प्रेरित करती है!

माइग्रेशन को निष्पादित करने और साथ ही नए डोमेन में काम को संभालने के लिए, हमने टीमों को दो समर्पित समूहों में विभाजित किया है। फीचर कार्य, जिसकी प्राथमिकता अधिक थी, के लिए अधिक संसाधनों की आवश्यकता थी और इसे तेज गति से दोहराने की आवश्यकता थी।

माइग्रेशन प्रक्रिया की अखंडता और व्यापक समझ सुनिश्चित करने के लिए, माइग्रेशन को संभालने के लिए विशेष रूप से जिम्मेदार एक छोटी समर्पित टीम को नियुक्त करना उचित होगा।

हालाँकि, हम पहले यह सुनिश्चित किए बिना फीचर कार्य को आगे नहीं बढ़ा सकते थे कि माइक्रो-फ्रंटएंड अवधारणा सफल साबित होगी।

जोखिमों को कम करने और एक स्पष्ट रोडमैप प्रदान करने के लिए, एक निम्न-स्तरीय डिज़ाइन दस्तावेज़ बनाना महत्वपूर्ण था जिसमें सटीक अनुमान और संपूर्ण जोखिम मूल्यांकन शामिल हो। यह दस्तावेज़ एक ब्लूप्रिंट के रूप में कार्य करता है, जो प्रवासन के लिए आवश्यक कदमों और विचारों को रेखांकित करता है।

इस प्रक्रिया में महत्वपूर्ण मील का पत्थर एक प्रूफ-ऑफ-अवधारणा का विकास था जो डिजाइन के अनुसार सभी घटकों के सफल एकीकरण को प्रदर्शित करेगा।

इस मील के पत्थर को उपयुक्त रूप से "प्वाइंट ऑफ नो रिटर्न" नाम दिया गया है, जिसका उद्देश्य माइक्रो-फ्रंटएंड आर्किटेक्चर की व्यवहार्यता और प्रभावशीलता को मान्य करना है।

हालाँकि मैं प्रवास की सफलता के बारे में आशावादी था, लेकिन आकस्मिकताओं के लिए तैयारी करना आवश्यक था। नतीजतन, मैंने एक योजना बी तैयार की, जो प्रारंभिक अवधारणा से वांछित परिणाम न मिलने की स्थिति में एक बैकअप रणनीति के रूप में काम करती थी।

इसमें विशेष रूप से मुझे तकिया में रोने के लिए अनुमान में अतिरिक्त सात दिन आवंटित करना शामिल था, साथ ही आलसी-लोडिंग के माध्यम से कोर से जुड़े एक नए फीचर मॉड्यूल प्रविष्टि के लिए कुछ दिन (वितरित मोनोलिथ याद रखें?)।

परिरूप

माइक्रो-फ़्रंटएंड डिज़ाइन करते समय, संरचना के लिए आम तौर पर 3 दृष्टिकोण होते हैं, प्रत्येक इस बात पर ध्यान केंद्रित करता है कि रनटाइम ऐप रिज़ॉल्यूशन कहाँ होता है। इन दृष्टिकोणों की सुंदरता यह है कि वे परस्पर अनन्य नहीं हैं और आवश्यकतानुसार इन्हें जोड़ा जा सकता है।

सर्वर-साइड संरचना

मूल विचार यह है कि प्रति पेज माइक्रो-फ्रंटेंड बंडलों को विभाजित करने और रूट यूआरएल के आधार पर हार्ड पेज रीलोड करने के लिए रिवर्स प्रॉक्सी सर्वर का लाभ उठाया जाए।

पेशेवर:

• कार्यान्वयन में सरल

दोष:

• वैश्विक स्थिति को माइक्रो-फ़्रंटएंड ऐप्स के बीच समन्वयित नहीं किया जाएगा। यह हमारे लिए स्पष्ट रूप से वर्जित बिंदु था क्योंकि हमारे पास क्लाइंट साइड पर लंबे समय से चल रहे पृष्ठभूमि संचालन थे।

  
  

  आप तर्क दे सकते हैं कि हम इस ऑपरेशन की "कतार" का एक स्नैपशॉट स्थानीय भंडारण में जारी रख सकते हैं और हार्ड-रीलोड के बाद इसे पढ़ सकते हैं, लेकिन सुरक्षा कारणों से, हम इसे लागू करने में सक्षम नहीं थे।

  
  

  यह वैश्विक स्थिति का सिर्फ एक उदाहरण है, लेकिन यहां एक और उदाहरण है कि यह कैसा दिख सकता है: साइडनेव पैनल की स्थिति (विस्तारित/संक्षिप्त), टोस्ट संदेश, आदि।

• माइक्रो-ऐप्स पर नेविगेट करते समय हार्ड रिफ्रेश बहुत ग्राहक अनुकूल नहीं है। सेवा कर्मियों का उपयोग करके साझा HTML को कैश करने का एक तरीका है लेकिन इसे बनाए रखना अतिरिक्त जटिलता है।

• बुनियादी ढांचे के लिए अतिरिक्त परिचालन और रखरखाव लागत: प्रत्येक माइक्रो-फ्रंटएंड ऐप के लिए प्रॉक्सी सर्वर (सीधे सीडीएन से पढ़ने पर इससे बचा जा सकता है), सामान्य (विक्रेता) निर्भरता को तैनात करने के लिए अलग बुनियादी ढांचा, कई पृष्ठों द्वारा पुन: उपयोग किया जा सकता है, और ठीक से ब्राउज़रों द्वारा कैश किया गया.

किनारे-किनारे की रचना

माइक्रो-फ़्रंटएंड कंपोज़िशन के लिए एक अन्य दृष्टिकोण एज-साइड कंपोज़िशन है, जिसमें किनारे की परत पर माइक्रो-फ़्रंटएंड का संयोजन शामिल है, जैसे कि सीडीएन। उदाहरण के लिए, अमेज़ॅन क्लाउडफ्रंट लैम्ब्डा@एज एकीकरण का समर्थन करता है, जो माइक्रो-फ्रंटएंड सामग्री को पढ़ने और परोसने के लिए साझा सीडीएन के उपयोग को सक्षम बनाता है।

पेशेवर:

• बनाए रखने के लिए कम बुनियादी ढांचे के टुकड़े: प्रॉक्सी सर्वर की आवश्यकता नहीं, प्रत्येक माइक्रो-ऐप के लिए अलग सीडीएन

• सर्वर रहित तकनीक का उपयोग करके वस्तुतः अनंत स्केलिंग

• स्टैंडअलोन प्रॉक्सी सर्वर की तुलना में बेहतर विलंबता

दोष:

• कोल्ड स्टार्ट टाइम एक मुद्दा बन सकता है

• यदि आपको बहु-क्षेत्रीय (पृथक) बुनियादी ढांचे की आवश्यकता है तो Lambda@Edge सभी AWS क्षेत्रों में समर्थित नहीं है

क्लाइंट-साइड संरचना

क्लाइंट-साइड कंपोज़िशन माइक्रो-फ़्रंटएंड आर्किटेक्चर का एक और दृष्टिकोण है जो क्लाइंट-साइड माइक्रो-फ़्रंटएंड ऑर्केस्ट्रेशन तकनीकों का उपयोग करता है, जो सर्वर कार्यान्वयन से अलग होता है।

इस आर्किटेक्चर में मुख्य खिलाड़ी एक कंटेनर (शेल) एप्लिकेशन है जिसकी निम्नलिखित जिम्मेदारियां हैं:

• क्रॉस-कटिंग चिंताओं को संबोधित करना: कंटेनर एप्लिकेशन केंद्रीकृत ऐप लेआउट, साइट नेविगेशन, पादलेख और सहायता पैनल को संभालता है। क्रॉस-कटिंग चिंताओं वाले माइक्रो-फ्रंटएंड के साथ एकीकरण एक इवेंट बस के माध्यम से होता है, जहां सिंथेटिक घटनाओं को वैश्विक विंडो दायरे में भेजा और प्रबंधित किया जाता है।

• माइक्रो-फ़्रंटएंड का ऑर्केस्ट्रेशन: कंटेनर ऐप यह निर्धारित करता है कि एप्लिकेशन की आवश्यकताओं और उपयोगकर्ता इंटरैक्शन के आधार पर कौन सा माइक्रो-फ़्रंटएंड बंडल लोड करना है और कब लोड करना है।

• वैश्विक निर्भरताएँ बनाना: कंटेनर ऐप सभी वैश्विक निर्भरताएँ, जैसे रिएक्ट, एसडीके और यूआई लाइब्रेरीज़ बनाता है, और उन्हें एक अलग बंडल (विक्रेता.जेएस) के रूप में उजागर करता है जिसे माइक्रो-फ्रंटएंड के बीच साझा किया जा सकता है।

सामान्य विचार यह है कि प्रत्येक माइक्रो-फ़्रंटएंड बंडल 2 प्रकार की संपत्ति फ़ाइलें तैयार करेगा:

• {हैश}/index.js: यह माइक्रो-फ़्रंटएंड एप्लिकेशन के लिए प्रवेश बिंदु के रूप में कार्य करता है, जिसमें हैश संपूर्ण बिल्ड के लिए एक अद्वितीय पहचानकर्ता का प्रतिनिधित्व करता है।

  
  

  हैश S3 बकेट में प्रत्येक बंडल के लिए एक उपसर्ग कुंजी के रूप में कार्य करता है। यह ध्यान रखना महत्वपूर्ण है कि एकाधिक प्रवेश बिंदु मौजूद हो सकते हैं, लेकिन हैश उन सभी के लिए समान रहता है।

• मैनिफ़ेस्ट.जेसन: यह एक मैनिफ़ेस्ट फ़ाइल है जिसमें माइक्रो-फ़्रंटएंड एप्लिकेशन के लिए सभी प्रवेश बिंदुओं के पथ शामिल हैं। यह फ़ाइल हमेशा S3 बकेट के रूट में छोड़ी जाएगी, जिससे कंटेनर इसे आसानी से खोज सकेगा।

  
  

  मैं परिवर्तनों की बेहतर अवलोकन क्षमता के लिए S3 बकेट में इस फ़ाइल के संस्करण को चालू करने की अनुशंसा करता हूं। यदि आप अपना प्रोजेक्ट बनाने के लिए वेबपैक का उपयोग कर रहे हैं, तो मैं WebpackManifestPlugin की अत्यधिक अनुशंसा करता हूं जो आपके लिए सभी भारी काम करता है।

कंटेनर को केवल स्टेज और क्षेत्र के आधार पर माइक्रो-फ्रंटएंड एसेट सोर्स डोमेन यूआरएल (सीडीएन मूल) के बारे में पता है। प्रारंभिक पृष्ठ लोड के दौरान, कंटेनर प्रत्येक माइक्रो-फ़्रंटएंड एप्लिकेशन के लिए मेनिफेस्ट फ़ाइल डाउनलोड करता है।

पेज लोड समय को प्रभावित करने से बचने के लिए मेनिफेस्ट फ़ाइल आकार में छोटी है (~100 बाइट्स) और एक कंटेनर के भीतर एकाधिक माइक्रो-फ़्रंटएंड को एकत्रित करते समय भी स्केल अच्छी तरह से होता है। आक्रामक कैशिंग को रोकने के लिए ब्राउज़र के कैश संग्रहण में मैनिफ़ेस्ट फ़ाइल को अपरिवर्तनीय मानना महत्वपूर्ण है।

सही ऑर्केस्ट्रेशन लाइब्रेरी का चयन करना इस रचना में सबसे बड़ी चुनौती है और इस पर अगले अध्याय में चर्चा की जाएगी।

पेशेवर:

• सर्वर कार्यान्वयन के प्रति अज्ञेयवादी: इस दृष्टिकोण को किसी विशिष्ट सर्वर आवश्यकताओं के बिना लागू किया जा सकता है, जो उपयोग की जाने वाली बैकएंड तकनीक में लचीलापन प्रदान करता है। जैसा कि ऊपर चित्र में दिखाया गया है, आपके पास कोई सर्वर नहीं भी हो सकता है

• वैश्विक स्थिति को संरक्षित करना: एक कंटेनर (शेल) ऐप का उपयोग करके, माइक्रो-फ्रंटएंड के बीच स्विच करते समय वैश्विक स्थिति को बनाए रखा जा सकता है। यह एक सहज उपयोगकर्ता अनुभव सुनिश्चित करता है और बदलाव के दौरान संदर्भ खोने से बचाता है।

• विकेंद्रीकृत दृष्टिकोण: प्रत्येक माइक्रो-फ़्रंटएंड स्वतंत्र रूप से यह तय कर सकता है कि बूटस्ट्रैप के लिए ब्राउज़र पर कौन सा डेटा भेजना है। कंटेनर ऐप बस एक अच्छी तरह से परिभाषित अनुबंध का पालन करता है, जो अधिक स्वायत्तता और मॉड्यूलरिटी की अनुमति देता है।

• सरल स्थानीय सेटअप: विकास आवश्यकताओं के आधार पर संपत्ति स्रोतों को उत्पादन और स्थानीय यूआरएल के बीच आसानी से समायोजित किया जा सकता है। मेनिफेस्ट फ़ाइल कंटेनर ऐप को आवश्यक माइक्रो-फ़्रंटएंड खोजने और लोड करने में मदद करती है। डेवलपर्स केवल कंटेनर और उन विशिष्ट माइक्रो-फ़्रंटएंड को चलाने पर ध्यान केंद्रित कर सकते हैं जिन पर वे काम कर रहे हैं।

दोष:

• मेनिफेस्ट फ़ाइल लाने के लिए अधिक नेटवर्क हॉप्स: चूंकि कंटेनर को प्रत्येक माइक्रो-फ़्रंटएंड के लिए मेनिफेस्ट फ़ाइल पुनर्प्राप्त करने की आवश्यकता होती है, इसलिए अन्य संरचना दृष्टिकोणों की तुलना में अतिरिक्त नेटवर्क अनुरोध और संभावित विलंबता हो सकती है। प्रारंभिक पृष्ठ लोड पर सभी मैनिफ़ेस्ट को अग्रिम रूप से लोड करके या कुछ प्रीलोडिंग तकनीकों को शुरू करके इसे कम किया जा सकता है।

• सामान्य अनुबंध का अनुपालन: प्रत्येक माइक्रो-फ़्रंटएंड को बिल्ड बनाने के लिए एक सामान्य अनुबंध का पालन करना होगा। इसे साझा कॉन्फ़िगरेशन और मानकीकृत विकास प्रथाओं के माध्यम से सुविधाजनक बनाया जा सकता है ताकि सूक्ष्म-फ्रंटएंड में स्थिरता सुनिश्चित की जा सके (इसके बारे में निम्नलिखित भागों में अधिक जानकारी दी जाएगी)।

संकर रचना

जैसा कि मैंने इस अध्याय में पहले उल्लेख किया है, इन सभी रचना पैटर्न को एक ही शेल एप्लिकेशन के भीतर मिश्रित और मिलान किया जा सकता है। यह कैसा दिख सकता है इसका एक उदाहरण यहां दिया गया है:

अनुशंसा

मैं शुरुआत में एक समरूप दृष्टिकोण के साथ शुरुआत करने की सलाह देता हूं - एक रचना पैटर्न चुनें जो आपके लिए बेहतर हो और उसके चारों ओर बुनियादी ढांचे का निर्माण शुरू करें।

हमारे लिए, क्लाइंट-साइड कंपोज़िशन सबसे अच्छा विकल्प था, लेकिन भविष्य के लिए, हमने कुछ क्षेत्रों को एज-साइड ऑर्केस्ट्रेशन (लैम्ब्डा@एज की उपलब्धता के आधार पर) पर स्विच करने पर विचार किया।

ऑर्केस्ट्रेशन लाइब्रेरी का चयन करना

जब माइक्रो-फ्रंटएंड आर्किटेक्चर में क्लाइंट-साइड संरचना को लागू करने की बात आती है, तो सही ऑर्केस्ट्रेशन लाइब्रेरी का चयन करना एक महत्वपूर्ण निर्णय है।

चुनी गई लाइब्रेरी कंटेनर एप्लिकेशन के भीतर माइक्रो-फ्रंटेंड की गतिशील लोडिंग और समन्वय को प्रबंधित करने में महत्वपूर्ण भूमिका निभाएगी।

कई लोकप्रिय ऑर्केस्ट्रेशन लाइब्रेरी मौजूद हैं, जिनमें से प्रत्येक की अपनी ताकत और विचार हैं।

सिंगल स्पा

सिंगल-स्पा एक व्यापक रूप से अपनाई गई ऑर्केस्ट्रेशन लाइब्रेरी है जो माइक्रो-फ्रंटएंड रचना के लिए एक लचीला और विस्तार योग्य दृष्टिकोण प्रदान करती है। यह डेवलपर्स को एक शेल एप्लिकेशन बनाने की अनुमति देता है जो कई माइक्रो-फ्रंटएंड की लोडिंग और अनलोडिंग को व्यवस्थित करता है।

सिंगल-एसपीए जीवनचक्र की घटनाओं पर सूक्ष्म नियंत्रण प्रदान करता है और विभिन्न रूपरेखाओं और प्रौद्योगिकियों का समर्थन करता है।

पेशेवर:

• फ़्रेमवर्क अज्ञेयवादी: लाइब्रेरी विभिन्न फ्रंटएंड फ़्रेमवर्क जैसे रिएक्ट, एंगुलर, Vue.js और अन्य के साथ अच्छी तरह से काम करती है।

• लचीला कॉन्फ़िगरेशन: यह रूटिंग, आलसी-लोडिंग और साझा निर्भरता के लिए शक्तिशाली कॉन्फ़िगरेशन विकल्प प्रदान करता है।

• मजबूत पारिस्थितिकी तंत्र: सिंगल-एसपीए में एक सक्रिय समुदाय और प्लगइन्स और एक्सटेंशन का एक समृद्ध पारिस्थितिकी तंत्र है।

दोष:

• सीखने की अवस्था: सिंगल-स्पा के साथ शुरुआत करने के लिए कुछ प्रारंभिक सीखने और इसकी अवधारणाओं और एपीआई को समझने की आवश्यकता हो सकती है।

• अनुकूलन जटिलता: जैसे-जैसे माइक्रो-फ़्रंटएंड आर्किटेक्चर जटिलता में बढ़ता है, ऑर्केस्ट्रेशन को कॉन्फ़िगर करना और प्रबंधित करना चुनौतीपूर्ण हो सकता है।

कियानकुन

कियानकुन एंट फाइनेंशियल (अलीबाबा) टीम द्वारा विकसित एक शक्तिशाली ऑर्केस्ट्रेशन लाइब्रेरी है। यह रचना के लिए आंशिक HTML दृष्टिकोण का उपयोग करता है। माइक्रो-फ़्रंटएंड ऐप साइड पर, यह लोड किए जाने वाले सभी प्रवेश बिंदुओं के साथ एक सादा HTML स्निपेट तैयार करता है।

इस HTML फ़ाइल का उपभोग करने के बाद, कंटेनर सभी ऑर्केस्ट्रेशन करता है और ऐप को माउंट करता है। इस कॉन्फ़िगरेशन में, आंशिक HTML एक मैनिफ़ेस्ट फ़ाइल की भूमिका निभाता है जिसके बारे में मैंने पिछले अध्याय में बात की थी।

पेशेवर:

• फ्रेमवर्क अज्ञेयवादी: कियानकुन विभिन्न फ्रंटएंड फ्रेमवर्क का समर्थन करता है, जिसमें रिएक्ट, वीयू.जेएस, एंगुलर और बहुत कुछ शामिल हैं।

• सरलीकृत एकीकरण: कियानकुन माइक्रो-फ्रंटएंड बनाने और प्रबंधित करने के लिए उपयोग में आसान एपीआई और टूल का एक सेट प्रदान करता है।

• स्केलेबिलिटी और प्रदर्शन: कियानकुन कोड सैंडबॉक्सिंग, राज्य अलगाव और माइक्रो-फ्रंटेंड के बीच संचार के लिए कुशल तंत्र प्रदान करता है।

दोष:

• निर्भरता संघर्ष: साझा निर्भरताओं को प्रबंधित करने और सूक्ष्म-फ्रंटएंड में अनुकूलता सुनिश्चित करने के लिए सावधानीपूर्वक कॉन्फ़िगरेशन और विचार की आवश्यकता हो सकती है।

• सीखने की अवस्था: जबकि कियानकुन व्यापक दस्तावेज़ीकरण प्रदान करता है, एक नई लाइब्रेरी को अपनाने से आपकी विकास टीम के लिए सीखने की अवस्था शामिल हो सकती है।

• तार पर भेजा गया अनावश्यक डेटा: आंशिक HTML स्निपेट में अनावश्यक डेटा (बॉडी, मेटा, DOCTYPE टैग) होता है जिसे नेटवर्क के माध्यम से भेजने की आवश्यकता होती है।

मॉड्यूल फेडरेशन

मॉड्यूल फेडरेशन , वेबपैक द्वारा प्रदान की गई एक सुविधा, ने वेब विकास समुदाय में महत्वपूर्ण ध्यान और प्रचार प्राप्त किया है। यह तकनीक डेवलपर्स को रनटाइम के दौरान कई एप्लिकेशन के बीच कोड साझा करने की अनुमति देती है, जिससे यह माइक्रो-फ्रंटएंड के निर्माण के लिए एक आकर्षक विकल्प बन जाता है।

वेबपैक और रनटाइम लचीलेपन के साथ अपने सहज एकीकरण के साथ, मॉड्यूल फेडरेशन माइक्रो-फ्रंटेंड के प्रबंधन और ऑर्केस्ट्रेटिंग के लिए एक लोकप्रिय विकल्प बन गया है।

पेशेवर:

• वेबपैक के साथ निर्बाध एकीकरण: यदि आप पहले से ही अपने निर्माण उपकरण के रूप में वेबपैक का उपयोग कर रहे हैं, तो मॉड्यूल फेडरेशन का लाभ उठाने से सेटअप और एकीकरण प्रक्रिया सरल हो जाती है।

• रनटाइम लचीलापन: मॉड्यूल फेडरेशन गतिशील लोडिंग और निर्भरताओं को साझा करने में सक्षम बनाता है, जो माइक्रो-फ्रंटेंड के प्रबंधन में लचीलापन प्रदान करता है।

दोष:

• सीमित फ्रेमवर्क समर्थन: जबकि मॉड्यूल फेडरेशन कई फ्रंटएंड फ्रेमवर्क के साथ संगत है, इसे विशिष्ट उपयोग के मामलों के लिए अतिरिक्त कॉन्फ़िगरेशन या वर्कअराउंड की आवश्यकता हो सकती है।

• सामुदायिक समर्थन: मॉड्यूल फेडरेशन एक अपेक्षाकृत नई तकनीक है, जिसे वेबपैक 5 में एक कोर प्लगइन के रूप में जारी किया गया (और बाद में इसे v4 पर वापस पोर्ट किया गया)। नेक्स्ट.जेएस लाइब्रेरी भी नई है, जिसे हाल ही में एक ओपन सोर्स के रूप में जारी किया गया है। जैसा कि सभी नए उपकरणों के साथ होता है, वहां एक छोटा समुदाय और कम समर्थन उपलब्ध हो सकता है। यदि आपके पास सीमित समय-सीमा है या आप आसानी से उपलब्ध उत्तरों के बिना प्रश्नों का सामना करने की आशा करते हैं, तो इस कारक पर विचार करना महत्वपूर्ण है।

निष्कर्ष

"माइक्रो-फ़्रंटएंड माइग्रेशन जर्नी" श्रृंखला के इस पहले भाग में, हमने एक वेब मोनोलिथ से वितरित आर्किटेक्चर में स्थानांतरित होने के पीछे की प्रेरणा और नेतृत्व को विचार बेचने के लिए उठाए गए शुरुआती कदमों पर चर्चा की है।

हमने एक तकनीकी दृष्टि दस्तावेज़ के महत्व का पता लगाया जो विस्तृत प्रदर्शन विश्लेषण प्रदर्शित करता है और प्रवासन के विभिन्न चरणों को रेखांकित करता है।

फिर हमने तीन दृष्टिकोणों पर चर्चा करते हुए माइक्रो-फ्रंटएंड के लिए डिज़ाइन संबंधी विचारों पर चर्चा की: सर्वर-साइड कंपोज़िशन, एज-साइड कंपोज़िशन, और क्लाइंट-साइड कंपोज़िशन।

प्रत्येक दृष्टिकोण के अपने फायदे और नुकसान हैं, और विकल्प विभिन्न कारकों पर निर्भर करता है जैसे वैश्विक स्थिति का सिंक्रनाइज़ेशन, ग्राहक अनुभव, बुनियादी ढांचे की जटिलता और कैशिंग।

इसके अलावा, हमने सिंगल-स्पा, कियानकुन और मॉड्यूल फेडरेशन जैसे लोकप्रिय ऑर्केस्ट्रेशन पुस्तकालयों की खोज की, उनकी विशेषताओं, लाभों और संभावित चुनौती पर प्रकाश डाला।

श्रृंखला के अगले भागों में मेरे साथ जुड़ें क्योंकि हम अपनी माइक्रो-फ़्रंटएंड माइग्रेशन यात्रा जारी रखते हैं, रास्ते में और अधिक दिलचस्प और मूल्यवान अंतर्दृष्टि को उजागर करते हैं!

मूल रूप से 18 अप्रैल, 2023 को https://thesametech.com पर प्रकाशित हुआ ।

आप मुझे ट्विटर पर भी फ़ॉलो कर सकते हैं, और नए पोस्ट के बारे में सूचनाएं प्राप्त करने के लिए लिंक्डइन पर भी जुड़ सकते हैं !