मोनोलिथ को तोड़ना: कोड बंटवारे की तकनीक के लिए एक व्यापक गाइड

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

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

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

माइक्रोफ्रंट दृष्टिकोण: यह क्या है और इसकी आवश्यकता क्यों है?

इससे पहले कि हम एमएफ की परिभाषा पर आगे बढ़ें, आइए उन कुछ समस्याओं पर गौर करें जिनका परियोजनाओं में सामना किया जा सकता है:

1. आपके पास एक बड़ी परियोजना है । एक परियोजना का आकार आमतौर पर व्यक्तिपरक होता है और अनुभवजन्य रूप से कार्यक्षमता की मात्रा और डेवलपर्स की संख्या से निर्धारित किया जा सकता है। यदि आपके पास 1-2 फ्रंट-एंडर्स को पहेली करने के लिए पर्याप्त काम है और साथ ही वे "अपनी कोहनी को आगे नहीं बढ़ाएंगे" - यह एक छोटी परियोजना है, 3-6 मध्यम है, और 6-8 से अधिक पहले से ही एक बड़ी परियोजना है .

   
   

2. आपके पास एक बड़ी टीम है । फिर, अनुभवजन्य रूप से, यह 10 से अधिक फ्रंट-एंडर्स हैं, बाकी प्रतिभागियों की गिनती नहीं है। एक नियम के रूप में, इस आकार की एक टीम को पहले से ही उप-टीमों में विभाजित किया जा सकता है जो समर्थन के लिए विशिष्ट कार्यक्षमता लेती हैं, और अपने स्वयं के विश्लेषकों, बैकएंडर्स और क्यूए का अधिग्रहण करती हैं।

   
   

3. आपके पास बड़ी कार्यक्षमता है। एक एकल डेवलपर केवल अपने उप-टीम के लिए कोड का एक टुकड़ा बनाए रख सकता है। विषय क्षेत्र की अज्ञानता या तीसरे पक्ष के तर्क को लागू करने की जटिलता के कारण शेष कोड को परिष्कृत करना महंगा हो सकता है।

और भी बढ़ सकती है परेशानी:

• ढेर को बदलने की इच्छा;

• संबंधित परियोजनाओं के एक परिवार का समर्थन करने के लिए एक कंपनी की आवश्यकता।

  
  

आप इतने सारे लोगों के बीच संबंध कैसे व्यवस्थित कर सकते हैं? आप इस पैमाने की परियोजना पर प्रक्रियाओं का निर्माण कैसे कर सकते हैं? आप जिम्मेदारी के क्षेत्रों को ठीक से कैसे चित्रित कर सकते हैं? आपने जितनी अधिक समस्याएं एकत्र की हैं, उतना ही यह सूक्ष्म-ललाट दृष्टिकोण की शुरूआत पर विचार करने योग्य है। चूंकि यह कोड और परियोजना टीम के अपघटन की दिशा में विकास की विकासवादी प्रवृत्ति का एक स्वाभाविक निरंतरता है।

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

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

माइक्रोफ्रंटेंड्स बनाम आलसी लोडिंग

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

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

एमएफ प्रदर्शन की समस्या का समाधान नहीं करते हैं, और कभी-कभी इसे बढ़ा भी देते हैं। लेकिन वे उपरोक्त समस्याओं को कम करते हुए विकास को इस तरह से व्यवस्थित करने में मदद करते हैं जो किसी विशेष उपटीम के लिए अधिक आरामदायक हो।

बिल्डटाइम बनाम रनटाइम

अब बात करते हैं एमएफ को एक ही एप्लीकेशन में मिलाने के दृष्टिकोण की। आप जो भी चुनते हैं, उसे उपयोगकर्ता को एक ही एप्लिकेशन की तरह दिखना चाहिए। आप उपयोगकर्ता के पक्ष में कोड निष्पादन के दौरान असेंबली चरण और गतिशील रूप से दोनों को मर्ज कर सकते हैं।

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

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

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

वर्जनिंग और स्वतंत्र परिनियोजन बहुत विरोधाभासी हैं:

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

  
  

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

  
  

वर्जनिंग को रनटाइम मर्जिंग के साथ भी लागू किया जा सकता है, लेकिन यह व्यावहारिक नहीं है। यह केवल स्वतंत्र परिनियोजन के लिए रनटाइम से संपर्क करने के लिए समझ में आता है, और बाद वाला वर्जनिंग के साथ मौजूद नहीं हो सकता है।

अगला, हम एमएफ के संयोजन के लिए प्रत्येक दृष्टिकोण के विशिष्ट कार्यान्वयन के उदाहरण देखेंगे।

माइक्रोफ्रंटेंड्स के आयोजन के लिए दृष्टिकोण

इफ्रेम

एमएफ को व्यवस्थित करने का सबसे पुराना तरीका। मुख्य साइट पर प्रदर्शित होने वाले संसाधन के पते को पारित करने के लिए iframe एक विशेष टैग है। परिणाम एक साइट के भीतर एक साइट है।

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

ये लाभ प्रदर्शन की लागत पर आते हैं, क्योंकि iframe के प्रत्येक सम्मिलन के परिणामस्वरूप संसाधनों का भार होता है। आप इससे बच नहीं सकते हैं: किसी DOM नोड को डीबग करने और पुनः जोड़ने का प्रयास पहले लोड किए गए संसाधनों को सहेज नहीं पाएगा, आपको उन्हें फिर से डाउनलोड करना होगा। आप कैशिंग को कॉन्फ़िगर करके प्रदर्शन गिरावट को कम कर सकते हैं।

ऐसा करने के लिए, आपको अपरिवर्तनीय संसाधनों के लिए समय-आधारित कैश अमान्यकरण को कॉन्फ़िगर करने की आवश्यकता है। सौभाग्य से, एकत्रित js और css फ़ाइलों के लिए बॉक्स से बाहर सभी आधुनिक cli नाम के लिए एक छोटा हैश संलग्न करते हैं। इस पद्धति के नुकसान में बाद के अनुक्रमण के लिए iframes प्रस्तुत करने के लिए खोज रोबोट की अक्षमता शामिल है।

वेबघटक

फ्रंट-एंड समुदाय लंबे समय से देशी घटकों के निर्माण की प्रतीक्षा कर रहा है, लेकिन अंत में, उन्हें कभी भी व्यापक लोकप्रियता नहीं मिली, जिसकी कई लोगों को उम्मीद थी। तीन सबसे लोकप्रिय फ्रंट-एंड फ्रेमवर्क (रिएक्ट, वीयू, एंगुलर) अभी भी अपने तरीके से घटक बनाते हैं।

वेब घटकों पर एमएफ बनाने की क्षमता के बावजूद, मैंने इसे व्यवहार में नहीं देखा है। और यह कोई दुर्घटना नहीं है, कई अवरोधक हैं:

• या तो लिब्स लिट या स्टैंसिल पर्याप्त लोकप्रिय नहीं है और पर्याप्त सामान्य नहीं है। इसके अलावा, बाजार में पर्याप्त विशेषज्ञ नहीं हैं जो जानते हैं कि उनके साथ कैसे काम करना है या जो सीखने के लिए तैयार हैं।

  
  

• कोणीय तत्व या व्यू-कस्टम-तत्व विदेशी रहते हैं। देशी वातावरण में, उनका उपयोग करने का कोई मतलब नहीं है। यदि आप पहले से ही एप्लिकेशन को सामान्य एनपीएम पैकेज में विभाजित कर चुके हैं, ताकि बाद में आप घटकों को अपनी पसंद से जोड़ सकें। अन्य ढांचे के साथ वेब घटकों का उपयोग करना अनुचित है क्योंकि जेनरेट किए गए घटकों के साथ, आपको उस ढांचे के मिनी-संस्करण को जोड़ने की आवश्यकता है जिस पर वे लिखे गए थे।

  
  

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

  
  

• खोज रोबोट एक वेब घटक नहीं बना सकते हैं, और यह एसईओ अनुकूलन को प्रभावित करेगा।

NPM

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

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

गिट सबमॉड्यूल्स (या Lerna की तरह मोनोरेपोज़ बनाने का दूसरा तरीका)

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

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

आइए दो तरीकों के बीच के अंतरों पर एक नज़र डालें:

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

  
  

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

  
  

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

  
  

एकल स्पा

सिंगल-स्पा अनिवार्य रूप से एक ढांचा है जो अन्य रूपरेखाओं को जोड़ता है। अविश्वसनीय रूप से शक्तिशाली तकनीक, जो बड़ी संख्या में बारीकियों को छुपाती है, एक अलग लेख का विषय है।

यह योजना iframe के समान है, लेकिन MF की लोडिंग अब नेटिव इम्पोर्ट + इम्पोर्टमैप या सिस्टमज के माध्यम से की जाती है, यदि पॉलीफ़िल की आवश्यकता हो।

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

वेबपैक 5 एम ओड्यूल फेडरेशन

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

योजना लगभग आमने-सामने एकल-स्पा दोहराती है, लेकिन अब एमएफ को लोड करने के लिए गतिशील आयात का उपयोग किया जाता है

कैसे चुनें कि आपके मामले में क्या उपयोग करना है?

आइए देखें कि क्या लागू किया जा सकता है और किसके लिए:

• iframe - असंगत के संयोजन के लिए एक एकल प्रविष्टि

• वेब घटक - जब आपको कॉर्पोरेट यूआई-किट की तरह एक ढांचे से बंधे बिना एक छोटी एंड-टू-एंड कार्यक्षमता की आवश्यकता होती है

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

• गिट सबमॉड्यूल - जब आपको किसी परियोजना को मोटे तौर पर काटने और जिम्मेदारी के क्षेत्रों को वितरित करने की आवश्यकता होती है

• सिंगल-स्पा - जब अनिश्चित काल के लिए, अधिमानतः SSR के बिना, कई रूपरेखाओं को संयोजित करने की प्रबल आवश्यकता होती है

• मॉड्यूल-फेडरेशन - एमएफ के उपयोग के लिए अन्य सभी परिदृश्य, स्टैक की एकता के अधीन।

  
  

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

और, ज़ाहिर है, उपयोगकर्ताओं के बारे में मत भूलना । अंततः, वे सभी जुड़े हुए ढांचे को डाउनलोड करते हैं और विभिन्न प्रकार की कार्यक्षमता में एमएफ के गलत एकीकरण से संभावित बगों को सहन करते हैं। व्यवसायों को बदले में इन सभी के कार्यान्वयन और समर्थन के लिए भुगतान करना होगा।