माइक्रोफ़्राँट: हम किस बारे में बात कर रहे हैं?

इन सभी वर्षों में, आप, सामने वाले डेवलपर ने मोनोलिथ लिखा है, हालांकि आप समझ गए थे कि यह एक बुरी आदत थी। आपने अपने कोड को घटकों में विभाजित किया, उपयोग किया या import और पैकेज में एनपीएम पैकेज को परिभाषित किया। अपनी परियोजना में गैस रिपोजिटरी या जेनिट रिपोजिटरी उत्पन्न की, लेकिन आपने वैसे भी एक मोनोलिथ लिखा।
यह स्थिति बदलने का समय है।

आपके कोड को एक मोनोलिथ क्यों माना जा सकता है?

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

माइक्रोसेवा क्या हैं?

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

माइक्रोसर्विस के साथ बातचीत करने वाले डेवलपर्स विभिन्न आकारों का नाम देते हैं। उनमें से सबसे बड़ी अमेज़ॅन की दो-पिज्जा टीम की रणनीति को पूरा करती है - 10-12 से अधिक लोग नहीं। रिवर्स पोल - 5-6 लोगों की टीम, जहां प्रत्येक एक सेवा का समर्थन करता है।

यहां एक आरेख और सूक्ष्मदर्शी के बीच अंतर को समझाते हुए एक आरेख है:



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



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

समस्या का समाधान: माइक्रोफ्रोनेट्स

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

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

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

सामान्य संरचना और कुछ और शब्दावली

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



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

समस्याओं का समाधान किया जाना है

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

समस्या संख्या 1: जब हम कई पूर्ण स्वायत्त माइक्रो-एप्लिकेशन होते हैं, तो UI से लगातार और निरंतर व्यवहार प्राप्त करते हैं

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

एक अन्य विकल्प रूट स्तर पर सामान्य सीएसएस चर बनाने के लिए है। इस समाधान का लाभ यह है कि हम सभी अनुप्रयोगों के लिए एक वैश्विक कस्टम थीम प्राप्त करते हैं।

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

समस्या संख्या 2: सुनिश्चित करें कि एक टीम किसी अन्य टीम के सीएसएस को फिर से नहीं लिखती है

सबसे पहले, आप माइक्रोएप्लीकेशन के नाम से गठित चयनकर्ताओं का उपयोग करके CSS के दायरे को सीमित कर सकते हैं। इस प्रतिबंध को मध्य स्तर पर रखकर, आप समग्र विकास समय को कम कर सकते हैं, लेकिन साथ ही, मध्य स्तरीय जिम्मेदारी बढ़ जाएगी।

दूसरे, आप प्रत्येक माइक्रो- मापक को एक कस्टम वेब घटक बना सकते हैं । इस दृष्टिकोण का लाभ यह है कि ब्राउज़र प्रतिबंध से संबंधित है। हालांकि, हर चीज की एक कीमत है: शैडो डोम के साथ, सर्वर साइड पर रेंडर करना लगभग असंभव है। इसके अलावा, कस्टम तत्व ब्राउज़र द्वारा समर्थित 100% नहीं हैं - खासकर यदि आपको IE समर्थन की आवश्यकता है।

समस्या संख्या 3: विभिन्न सूक्ष्म अनुप्रयोगों के लिए वैश्विक जानकारी को सामान्य बनाएं

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

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

समस्या संख्या 4: यदि सभी माइक्रो-एप्लिकेशन स्वायत्त हैं, तो क्लाइंट की तरफ रूटिंग कैसे करें?

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

मेरा व्यावहारिक दृष्टिकोण एक सामान्य ग्राहक राउटर बनाना है, जो केवल शीर्ष-स्तरीय मार्गों के लिए जिम्मेदार है, और बाकी सभी संबंधित माइक्रो-अनुप्रयोगों की दया पर है। मान लें कि हमारे पास एक मार्ग परिभाषा /content/:id. सामान्य राउटर c /content को हल कर देगा, और हल किया गया रास्ता ContentMicroApp को पास कर दिया जाएगा। ContentMicroApp एक स्टैंडअलोन सर्वर है जिसे केवल /:id साथ बुलाया जाएगा।

समस्या संख्या 5: क्या हमें वास्तव में SSR (सर्वर-साइड रेंडरिंग) की आवश्यकता है, क्या यह माइक्रोफ्रोनेट्स का उपयोग करते समय संभव है?

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

समस्या 6: “मौजूदा वातावरण के साथ एकीकरण की आवश्यकता हवा की तरह है! इसे कैसे बनाया जाए? ”

मौजूदा प्रणालियों के साथ एकीकरण के लिए, मैं अपनी दृष्टि का वर्णन करना चाहता हूं, जिसे मैं " क्रमिक कार्यान्वयन " कहता हूं।

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

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

अब LegacyMicroApp , नेविगेशनमाइक्रोऐप निर्भरता के माध्यम से सभी मार्गों को बाधित करेगा और इसे आंतरिक रूप से संसाधित करेगा।

फिर, इसी तरह, हम पाद लेख का रीमेक बनाएंगे।

इसलिए हम LegacyMicroApp के एक टुकड़े को तब तक काटते रहेंगे जब तक कि उसमें से कुछ भी नहीं निकलता ।

समस्या संख्या 7: क्लाइंट साइड को ऑर्केस्ट्रेट करें ताकि आपको हर बार पृष्ठ को फिर से लोड न करना पड़े

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

ऊपर सूचीबद्ध समस्याओं को निम्नलिखित विषयों में जोड़ा जा सकता है:

ग्राहक पक्ष

• वाद्य-स्थान
• मार्ग
• सूक्ष्म अलगाव
• आवेदन बातचीत
• एकता यूआई माइक्रो-अनुप्रयोग

सर्वर साइड

• सर्वर रेंडरिंग
• मार्ग
• निर्भरता प्रबंधन

लचीली और शक्तिशाली लेकिन सरल वास्तुकला

इस के लिए, यह लेख की शुरुआत को समाप्त करने के लायक था! मुख्य तत्व और माइक्रोफ्रॉस्टेंड वास्तुकला की आवश्यकताएं अंततः उभरने लगी हैं;)

आवश्यकताओं और चिंताओं से प्रेरित होकर, मैंने माइक्रोफ़ नामक एक समाधान विकसित करना शुरू किया। * प्रतिक्रिया की प्रत्याशा *
यहां मैं परियोजना के स्थापत्य की रूपरेखा तैयार करूंगा, इसके मुख्य घटकों का संक्षेप में वर्णन करूंगा।

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



AppsManager
AppsManager क्लाइंट-साइड माइक्रो-एप्लिकेशन ऑर्केस्ट्रेशन का मूल है। AppsManager का मुख्य लक्ष्य एक निर्भरता ट्री बनाना है। एक बार सभी निर्भरताएँ हल हो जाने के बाद, AppsManager ने माइक्रोएप्लीकेशन लॉन्च किया।

लोडर
क्लाइंट साइड ऑर्केस्ट्रेशन का एक अन्य महत्वपूर्ण हिस्सा लोडर है। वह क्लाइंट साइड के लिए एप्लिकेशन डाउनलोड करने के लिए जिम्मेदार है।

रूटर
क्लाइंट-साइड रूटिंग करने के लिए, मैंने राउटर को माइक्रोफ़े में लागू किया। पारंपरिक क्लाइंट-साइड राउटर के विपरीत, माइक्रोफ़े राउटर की सीमित कार्यक्षमता है। यह पृष्ठों को संसाधित नहीं करता है, लेकिन माइक्रो-एप्लिकेशन। मान लें कि हमारे पास URL /content/detail/13 और ContentMicroApp है। इस स्थिति में, माइक्रोफ़ाइ राउटर URL को /content/* संसाधित करेगा और ContentMicroApp /detail/13 कॉल करेगा।

MicroAppStore
माइक्रो-एप्लिकेशन के बीच क्लाइंट इंटरेक्शन को हल करने के लिए, मैंने माइक्रोफ़ास्ट को माइक्रोफ़ में लागू किया। इसमें Redux लाइब्रेरी की तरह ही कार्यक्षमता है, लेकिन एक चेतावनी के साथ: यह अतुल्यकालिक डेटा संशोधन और reducer'a घोषणा के संबंध में अधिक लचीला है।

***

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

MicroAppServer

सबसे छोटा संभव MicroAppServer कार्यक्षमता के रूप में व्यक्त किया जा सकता है: init और सेवा।
जब MicroAppServer बूट होता है, तो सबसे पहले इसे करना चाहिए SticthingServer को कॉल करें और घोषित माइक्रो-एप्लिकेशन के साथ एक समापन बिंदु पंजीकृत करें। यह MicroAppServer योजना की निर्भरता, प्रकार और URL को परिभाषित करता है। मुझे लगता है कि सेवा के बारे में बात करना अनावश्यक है - यहां कुछ भी दिलचस्प नहीं है।

सिलाई सर्वर

StitchingServer आपको MicroAppServers के साथ एक समापन बिंदु पंजीकृत करने की अनुमति देता है। जब MicroAppServer StichingServer के साथ रजिस्टर होता है, तो StichingServer MicroAppServer घोषणा को रिकॉर्ड करता है।

बाद में, StitchingServer अनुरोधित URL से MicroAppServices को हल करने के लिए विज्ञापन का उपयोग करता है।

MicroAppServer और इसकी सभी निर्भरता की अनुमति देने के बाद, संबंधित सार्वजनिक URL CSS, JS और HTML में सभी संबंधित पथों के नाम में दिखाई देगा। एक अतिरिक्त कदम ग्राहक पक्ष पर सूक्ष्म अनुप्रयोगों के बीच संघर्ष को रोकने के लिए CSS चयनकर्ताओं के लिए एक अद्वितीय MicroAppServer उपसर्ग जोड़ना है।

तब StitchingServer का मुख्य कार्य दृश्य में प्रवेश करता है: प्राप्त किए गए सभी भागों को इकट्ठा करना और पूरे HTML पृष्ठ को वापस करना।

अन्य कार्यान्वयन के बारे में कुछ शब्द

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

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

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

निष्कर्ष (और लिंक)

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

माइक्रो फ़े ऐप रजिस्ट्री सर्वर
माइक्रो फ्रंट एंड इंफ्रास्ट्रक्चर