मायक्रोफ्रंटएंड्स कसे कार्य करतात: आर्किटेक्चर, नमुने आणि उदाहरणे

होम पेज » python ला » मायक्रोफ्रंटएंड्स कसे कार्य करतात: आर्किटेक्चर, नमुने आणि उदाहरणे

मायक्रोफ्रंटएंड्स हे सर्वात जास्त चर्चेत असलेल्या फ्रंटएंड आर्किटेक्चर पॅटर्नपैकी एक बनले आहेत. क्लासिक सिंगल-पेज मोनोलिथपेक्षा जास्त वाढलेल्या संघांसाठी. जेव्हा तुमच्याकडे डझनभर डेव्हलपर्स एकाच कोडबेसला स्पर्श करतात तेव्हा रिलीज सायकल मंदावतात, सर्वत्र रिग्रेशन्स येतात आणि लहान UI बदलांना अचानक मोठ्या प्रमाणात समन्वयाची आवश्यकता असते. मायक्रोफ्रंटएंड्स UI ला स्वतंत्रपणे तयार केलेल्या आणि तैनात केलेल्या तुकड्यांमध्ये कापून त्याच समस्येवर हल्ला करतात.

या मार्गदर्शकामध्ये आपण मायक्रोफ्रंटएंड्स म्हणजे काय, ते का दिसले, ते मायक्रोसर्व्हिसेसशी कसे संबंधित आहेत याबद्दल चर्चा करू., डिझाइन करताना तुम्ही कोणत्या मुख्य कल्पनांचा आदर केला पाहिजे आणि React, Angular, Next.js, Web Components, Webpack Module Federation आणि Single‑SPA सारख्या तंत्रज्ञानासह ते कसे कार्य करतात. आम्ही वास्तविक वास्तुशिल्प नमुने, चांगल्या पद्धती, सामान्य तोटे आणि स्वतंत्र मायक्रोफ्रंटएंड म्हणून अंमलात आणलेले उत्पादन कॅटलॉग आणि कार्ट सारख्या ठोस उदाहरणांचा देखील शोध घेऊ.

मायक्रोफ्रंटएंड्स म्हणजे काय आणि ते का दिसले?

"मायक्रो फ्रंटएंड्स" हा शब्द २०१६ च्या सुमारास थॉटवर्क्स टेक्नॉलॉजी रडारमध्ये लोकप्रिय झाला. एका अतिशय ठोस ट्रेंडला उत्तर म्हणून: बॅकएंड आर्किटेक्चर्स मायक्रोसर्व्हिसेसकडे जात होते, परंतु ब्राउझरची बाजू एकाच टीमच्या मालकीची एक मोठी, ठिसूळ मोनोलिथ राहिली. कालांतराने तो "फॅट क्लायंट" एसपीए विकसित करणे कठीण होते, जरी बॅकएंड लहान सेवांमध्ये विभागलेला असला तरी.

मायक्रोफ्रंटएंड ही मूलतः ब्राउझर UI वर लागू केलेली मायक्रोसर्व्हिस कल्पना आहे.: एका मोठ्या फ्रंटएंड रिपॉझिटरीऐवजी, तुम्ही अनेक लहान, स्वयंपूर्ण अनुप्रयोगांमधून वापरकर्ता इंटरफेस तयार करता. प्रत्येकाकडे एक स्पष्ट व्यवसाय डोमेन आहे (उदाहरणार्थ, "चेकआउट", "उत्पादन शोध", "विद्यार्थी प्रोफाइल") आणि ते स्वतःच्या कॅडेन्सवर तयार केले जाऊ शकते, चाचणी केली जाऊ शकते आणि तैनात केले जाऊ शकते.

ज्याप्रमाणे मायक्रोसर्व्हिसेस बॅकएंड लॉजिकला वेगळ्या डिप्लॉय करण्यायोग्य युनिट्समध्ये विभाजित करतात, त्याचप्रमाणे मायक्रोफ्रंटएंड फ्रंटएंडला उभ्या स्लाइसमध्ये विभाजित करतात. जे डेटाबेस किंवा एपीआय पासून, बॅकएंड पासून, युजर इंटरफेस पर्यंत पसरलेले असते. एका क्रॉस-फंक्शनल टीमकडे डेटा स्कीमा ते UI घटकांपर्यंत, एंड-टू-एंड पर्यंत त्या उभ्या स्लाइसची मालकी असते.

ही "उभी संघटना" थरांनी केलेल्या क्षैतिज विभाजनाशी तुलना करते. (एक टीम UI साठी, दुसरी API साठी, दुसरी डेटाबेससाठी). उभ्या टीम जलद गतीने पाठवल्या जातात कारण त्यांना अर्ध्या कंपनीमध्ये प्रत्येक लहान बदलाचे समन्वय साधण्याची आवश्यकता नसते.

अनुप्रयोगाच्या दृष्टिकोनातून, मायक्रोफ्रंटएंड हा एक स्वायत्त वेब अनुप्रयोग आहे. ते एका मोठ्या अनुभवात तयार केले जाऊ शकते: जर ते उर्वरित सिस्टम (URL, इव्हेंट्स, API, शेअर्ड लायब्ररी इ.) सह करारांच्या संचाचे पालन करते तर त्याचे स्वतःचे रूटिंग, स्टेट मॅनेजमेंट, डिझाइन सिस्टम आणि डिप्लॉयमेंट पाइपलाइन असू शकते.

मायक्रोफ्रंटएंड्समागील मुख्य कल्पना आणि तत्त्वे

यशस्वी मायक्रोफ्रंटएंड आर्किटेक्चरमध्ये अनेक आवर्ती तत्वे दिसून येतात.; ते कडक नियम नाहीत पण जर तुम्ही त्यांचा वापर रेलिंग म्हणून केला तर ते तुम्हाला खूप त्रासापासून वाचवतील.

तंत्रज्ञान अज्ञेयवाद हे सर्वात प्रसिद्ध तत्वांपैकी एक आहे: प्रत्येक संघाला इतर सर्वांशी सिंक्रोनाइझ न करता त्यांचे टेक स्टॅक निवडता आणि अपग्रेड करता आले पाहिजे. कदाचित एक मायक्रोफ्रंटएंड React वर असेल, दुसरा Angular मध्ये असेल आणि दुसरा Vue मध्ये असेल. कस्टम एलिमेंट्स (वेब ​​कॉम्पोनंट्स) सारखे ब्राउझर-नेटिव्ह अ‍ॅबस्ट्रॅक्शन्स मानक DOM API च्या मागे ते फरक लपविण्यात मदत करतात.

टीम कोडबेसमधील मजबूत अलगाव हे आणखी एक महत्त्वाचे ध्येय आहे.. आदर्शपणे, मायक्रोफ्रंटएंड्स जावास्क्रिप्ट रनटाइम किंवा ग्लोबल व्हेरिएबल्स शेअर करत नाहीत. प्रत्येक बंडल स्वयंपूर्ण आहे, स्वतःचे अवलंबित्व लोड करतो आणि इतरांकडून लपलेल्या स्थितीवर अवलंबून नाही. यामुळे अपघाती जोडणी कमी होते आणि स्वतंत्र उपयोजन अधिक वास्तववादी बनते.

नावे देण्याच्या संघर्ष टाळण्यासाठी, संघ अनेकदा स्पष्ट नेमस्पेसेसवर सहमत होतात. CSS वर्ग, DOM कार्यक्रम, लोकलस्टोरेज की, कुकीज किंवा अगदी कस्टम एलिमेंट टॅग नावांसाठी. उदाहरणार्थ, चेकआउट टीम गोष्टींना chk- किंवा सारखा टॅग वापरा <blue-buy>, तर शिफारस पथक वापरते rec- or <green-recos>. एका दृष्टीक्षेपात, DOM तुम्हाला सांगते की कोणता तुकडा कोणाचा आहे.

दुसरे तत्व म्हणजे कस्टम ग्लोबल एपीआयपेक्षा नेटिव्ह ब्राउझर क्षमतांना प्राधान्य देणे.. सर्व-उद्देशीय पबसब सिस्टम शोधण्याऐवजी, तुम्ही मानक DOM इव्हेंट्सवर अवलंबून राहू शकता, CustomEvent, रूटिंगसाठी इतिहास API किंवा इंटिग्रेशन लेयर म्हणून DOM स्वतः. जेव्हा तुम्हाला खरोखर शेअर्ड API ची आवश्यकता असेल तेव्हा ते शक्य तितके लहान आणि स्थिर ठेवा.

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

या संदर्भात "आधुनिक वेब अॅप्लिकेशन" म्हणजे काय?

प्रत्येक वेबसाइटला मायक्रोफ्रंटएंड्स किंवा जटिल ब्राउझर इंटिग्रेशन स्ट्रॅटेजीची आवश्यकता नसते.. एक चांगले मानसिक मॉडेल "कागदपत्रे ते अनुप्रयोग सातत्य" मधून येते: डावीकडे बहुतेक स्थिर कागदपत्रे एकमेकांशी जोडलेली असतात; उजवीकडे ऑनलाइन फोटो एडिटरसारखे पूर्णपणे परस्परसंवादी अॅप्स असतात.

जर तुमचा प्रकल्प स्थिर दस्तऐवजांच्या जवळ असेल, तर एक साधी सर्व्हर-रेंडर केलेली रचना अनेकदा पुरेशी असते.. सर्व्हर वेगवेगळ्या स्रोतांमधून HTML तुकडे गोळा करतो, त्यांना एकत्र जोडतो आणि ब्राउझरला पाठवतो. अपडेट्स पूर्ण पृष्ठ लोड किंवा लहान Ajax इंजेक्शनद्वारे होतात आणि ते अगदी ठीक आहे.

जेव्हा तुम्ही अधिक गतिमान, अॅपसारखे अनुभव मिळवता तेव्हा— त्वरित अभिप्राय, ऑफलाइन काम करणे, आशावादी UI अपडेट्स — शुद्ध सर्व्हर-साइड इंटिग्रेशन पुरेसे नाही. तुम्हाला क्लायंट-साइड कंपोझिशन, स्टेट मॅनेजमेंट आणि राउटिंगची आवश्यकता आहे. तिथेच मायक्रोफ्रंटएंड्स मनोरंजक बनतात: ते तुम्हाला अनेक टीममध्ये ती जटिलता मोजण्याचा मार्ग देतात.

उभ्या संघटना आणि डोमेन-चालित स्लाइस

तांत्रिक स्तरांऐवजी व्यवसाय डोमेनसह मायक्रोफ्रंटएंड्स संरेखित करणे ही एक सामान्य शिफारस आहे.. वापरकर्त्यांच्या प्रवासाच्या संदर्भात विचार करा: “कार्ट”, “उत्पादन तपशील”, “प्रशासक वापरकर्ते”, “अभ्यासक्रम वेळापत्रक”, “विद्यार्थी रेकॉर्ड”, “इनव्हॉइस”, इ.

यापैकी प्रत्येक डोमेन एक सुस्पष्ट जबाबदारीसह स्वतःचे मायक्रोफ्रंटएंड बनू शकते.. विद्यापीठ प्रणालीमध्ये, एक अॅप विद्यार्थ्यांचे प्रोफाइल, दुसरे कर्मचारी प्रोफाइल, तिसरे अभ्यासक्रम वेळापत्रक आणि दुसरे परीक्षेचे निकाल UI व्यवस्थापित करू शकते. ते एक शेल आणि कदाचित काही स्टाइलिंग सामायिक करतात, परंतु प्रत्येक अनुप्रयोग तैनाती दृष्टिकोनातून एक स्वतंत्र अनुप्रयोग आहे.

चांगले स्लाइसिंग तुमच्या बॅकएंड मायक्रोसर्व्हिसेसच्या मर्यादित संदर्भांचा देखील विचार करते.. आदर्शपणे, "बिलिंग" साठी मायक्रोफ्रंटएंड प्रामुख्याने बिलिंग मायक्रोसर्व्हिसेसशी बोलतो, "कॅटलॉग" फ्रंटएंड कॅटलॉग सेवांशी बोलतो, इत्यादी. यामुळे प्रत्येक उभ्या स्लाइसला एकसंध ठेवता येते आणि क्रॉस-टीम अवलंबित्व कमी होते.

तांत्रिक एकत्रीकरण: API आणि वेब घटक म्हणून DOM

ब्राउझर-साइड मायक्रोफ्रंटएंड आर्किटेक्चरमध्ये, DOM स्वतःच बहुतेकदा प्राथमिक एकत्रीकरण API म्हणून काम करते.. एकमेकांच्या जावास्क्रिप्टला थेट कॉल करण्याऐवजी, टीम्स HTML घटक, गुणधर्म आणि कार्यक्रमांद्वारे कार्यक्षमता उघड करतात.

कस्टम एलिमेंट्स (वेब ​​कंपोनेंट्सचा भाग) यासाठी एक शक्तिशाली आदिम आहेत. एक टीम त्याला हवे असलेले कोणतेही फ्रेमवर्क वापरून एक वैशिष्ट्य तयार करू शकते आणि नंतर ते कस्टम टॅग म्हणून गुंडाळू शकते, उदाहरणार्थ <order-minicart></order-minicart>. त्या घटकाचा सार्वजनिक करार त्याच्या टॅग नावाने, गुणधर्मांनी आणि उत्सर्जित घटनांद्वारे परिभाषित केला जातो, त्याच्या अंतर्गत अंमलबजावणीद्वारे नाही.

कस्टम एलिमेंट्स v1 साठी ब्राउझर सपोर्ट आता सर्व प्रमुख ब्राउझरमध्ये चांगला आहे., म्हणजे तुम्हाला क्वचितच पॉलीफिलची आवश्यकता असते. बहुतेक मुख्य प्रवाहातील फ्रेमवर्क - React, Vue, Angular, Svelte, Preact - कस्टम एलिमेंट्स रेंडर किंवा एम्बेड करू शकतात जसे की ते नियमित HTML टॅग आहेत आणि त्यापैकी बरेच स्वतः कस्टम एलिमेंटमध्ये देखील संकलित केले जाऊ शकतात.

एकत्रीकरण नमुना असे दिसते.: "उत्पादन पृष्ठ" मायक्रोफ्रंटएंड पृष्ठावर कोणती वैशिष्ट्ये दिसावीत हे ठरवते (निवडक, खरेदी बटणे, मिनी-कार्ट, शिफारसी). ते कस्टम घटक इंजेक्ट करते जसे की <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>. ज्या संघांकडे ही वैशिष्ट्ये आहेत ते त्यांचे घटक नोंदणीकृत करतात customElements.define आणि लाइफसायकल कॉलबॅक अंमलात आणा जसे की connectedCallback or attributeChangedCallback.

जेव्हा उत्पादन प्रकार बदलतो, तेव्हा पृष्ठ एकतर घटक पुन्हा तयार करू शकते किंवा त्याचे गुणधर्म अद्यतनित करू शकते.. जर घटक संबंधित गुणधर्मांचे निरीक्षण करत असेल, तर तो स्वतःला पुन्हा प्रस्तुत करू शकतो. अंतर्गतरित्या, घटक टेम्पलेट स्ट्रिंग, React, Vue किंवा कोणतेही रेंडरिंग इंजिन वापरू शकतो; इंटिग्रेटरला काळजी करण्याची आवश्यकता नाही.

क्लायंट-साइड कम्युनिकेशन: इव्हेंट्स आणि DOM संबंध

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

कस्टम ग्लोबल इव्हेंट बस तयार करण्याऐवजी, तुम्ही ब्राउझर इव्हेंट्सवर अवलंबून राहू शकता.. घटकांचे प्रेषण CustomEvent DOM ट्रीमधून बबल होणारे प्रसंग. एक मूळ घटक किंवा अगदी window त्या कार्यक्रमांचे ऐकू शकतात आणि प्रतिसादांचे आयोजन करू शकतात.

उदाहरणार्थ, खरेदी बटण कदाचित अशी घटना उत्सर्जित करेल blue:basket:changed सध्याच्या कार्ट पेलोडसह. मिनी-कार्ट त्या कार्यक्रमाचे सदस्यत्व घेते window किंवा शेअर्ड कंटेनर एलिमेंटवर आणि जेव्हा ते फायर होते तेव्हा त्याची अंतर्गत स्थिती रिफ्रेश करते.

हा दृष्टिकोन घटकांना स्वतंत्र ठेवतो: बाय बटणाला माहित नसते की त्याच्या कार्यक्रमांसाठी कोण, जर कोणी असेल तर, ऐकतो. ते फक्त त्याचा करार पूर्ण करते. आणि मिनी-कार्ट फक्त कार्यक्रमाच्या अर्थशास्त्रावर अवलंबून असते, इतर तुकड्यांच्या अंमलबजावणी तपशीलांवर नाही.

सर्व्हर-साइड रेंडरिंग आणि युनिव्हर्सल घटक

जर तुम्हाला पहिल्या रंगाच्या कामगिरीची, एसइओची किंवा जावास्क्रिप्ट अयशस्वी झाल्यावर लवचिकतेची काळजी असेल, तर सर्व्हर-साइड रेंडरिंग (SSR) आवश्यक आहे.. शुद्ध क्लायंट-साइड वेब घटक फक्त JS बंडल डाउनलोड आणि रन झाल्यानंतर दिसतात, ज्याचा अर्थ स्लो नेटवर्क्सवर पांढरा स्क्रीन असू शकतो.

एक व्यावहारिक उपाय म्हणजे कस्टम एलिमेंट्सना सर्व्हर-साइड इनक्लुड्स (SSI/ESI) सह एकत्र करणे.. प्रत्येक मायक्रोफ्रंटएंड एक HTTP एंडपॉइंट उघड करतो जो त्याच्या तुकड्यासाठी HTML परत करतो, उदाहरणार्थ /blue-buy?sku=t_porsche. शेल किंवा होस्ट अॅप्लिकेशनद्वारे प्रस्तुत केलेल्या मुख्य पृष्ठामध्ये प्लेसहोल्डर समाविष्ट असतात जसे की <!--#include virtual="/blue-buy?sku=t_porsche" --> जे वेब सर्व्हर (बहुतेकदा nginx) ब्राउझरला प्रतिसाद पाठवण्यापूर्वी विस्तृत करते.

ब्राउझरमध्ये रनटाइम करताना, तोच कस्टम घटक हायड्रेटेड किंवा पुन्हा सुरू केला जातो. एकदा त्याचे JS बंडल लोड झाले की. ते तुम्हाला एक "युनिव्हर्सल" घटक देते: ते सर्व्हरवर गती आणि SEO साठी रेंडर करू शकते, नंतर क्लायंटवर पूर्णपणे परस्परसंवादी कस्टम घटकासारखे वागू शकते.

समावेश असलेल्या SSR चा एक तोटा म्हणजे सर्वात मंद तुकडा एकूण प्रतिसाद वेळेवर अवलंबून असतो.. फ्रॅगमेंट लेव्हलवर कॅशिंग करणे जवळजवळ अनिवार्य आहे. महागड्या, अत्यंत वैयक्तिकृत तुकड्यांसाठी (जसे की शिफारसी) तुम्ही सर्व्हर-साइड रेंडरिंग वगळू शकता आणि त्यांना क्लायंटवर असिंक्रोनसली लोड करू शकता.

लेआउटमध्ये होणारे बदल टाळण्यासाठी स्केलेटन स्क्रीन ही एक चांगली तडजोड आहे.. एक तुकडा सर्व्हरवर राखाडी रंगाचा प्लेसहोल्डर देऊ शकतो ज्याचा आकार अंतिम सामग्रीइतकाच असतो. जेव्हा वास्तविक डेटा क्लायंट-साइडवर येतो तेव्हा मोठ्या रिफ्लोशिवाय सांगाडा बदलला जातो.

डेटा लोडिंग आणि समजलेली कामगिरी

मायक्रोफ्रंटएंड जगात तुम्हाला डेटा कुठे आणि केव्हा मिळवायचा याचा काळजीपूर्वक विचार करावा लागेल.. तुम्ही सर्व्हर-साइड, क्लायंट-साइड सर्वकाही मिळवू शकता किंवा हायब्रिड वापरू शकता. प्रत्येक निवड कॅशिंग स्ट्रॅटेजीज, टाइम-टू-इंटरॅक्टिव्ह आणि कथित गतीवर परिणाम करते.

सर्व्हर-साईडमध्ये नैसर्गिकरित्या प्रत्येक तुकड्यावर सर्व्हर-साईड फेचला प्रोत्साहन देणे समाविष्ट आहे. प्रत्येक मायक्रोफ्रंटएंड "त्याच्या" बॅकएंड सेवांशी बोलतो, HTML रेंडर करतो आणि ते शेलमध्ये परत करतो. ते HTML इतर तुकड्यांपासून स्वतंत्रपणे कॅशे केले जाऊ शकते, जे लॉगिन किंवा उत्पादन सूची सारख्या उच्च-ट्रॅफिक भागांना स्केल करण्यास मदत करते.

क्लायंटवर डेटा लोड करताना तुम्ही प्रगतीशील राज्यांसाठी बजेट तयार केले पाहिजे.: प्रारंभिक स्केलेटन, गुणधर्म बदलल्यावर जलद अपडेट्स आणि API ची गती कमी असताना फॉलबॅक वर्तन. कधीकधी नवीन डेटा येईपर्यंत जुना डेटा त्याच ठिकाणी ठेवणे हे प्रत्येक किरकोळ बदलासाठी स्केलेटन फ्लॅश करण्यापेक्षा दृश्यमानपणे कमी त्रासदायक असते.

React सह मायक्रोफ्रंटएंड्स

मायक्रोफ्रंटएंड्स लागू करण्यासाठी रिअॅक्ट हा एक अतिशय लोकप्रिय पर्याय आहे कारण त्याच्या इकोसिस्टम आणि रेंडरिंग ऑप्टिमायझेशनमुळे.. व्हर्च्युअल DOM आणि डिफिंगमुळे प्रोप बदल किंवा ग्लोबल स्टेटवर आधारित UI चे छोटे भाग अपडेट करणे सोपे होते आणि तुम्ही React अॅप्स स्टँडअलोन SPA किंवा कस्टम एलिमेंट्स म्हणून एकत्रित करू शकता.

React आवृत्त्यांमधील स्थलांतर हे हळूहळू आणि तुलनेने वेदनारहित असते. इतर काही फ्रेमवर्कच्या तुलनेत, जे अनेक स्वतंत्र संघ स्वतंत्र मायक्रोफ्रंटएंड राखतात तेव्हा उपयुक्त ठरते. एकाच वेळी एका प्रमुख आवृत्तीवरून दुसऱ्या आवृत्तीवर जाण्यासाठी तुम्हाला सर्व तुकड्यांची आवश्यकता नाही.

दुसरी बाजू अशी आहे की विकेंद्रित रिएक्ट मायक्रोफ्रंटएंड्स संसाधनांचा प्रसार निर्माण करू शकतात.: अनेक टीम्स, अनेक CI/CD पाइपलाइन्स, अनेक बंडल, अनेक लहान रिपो. बिल्ड, प्रोव्हिजनिंग आणि ऑब्झर्व्हेबिलिटीसाठी पुरेसे ऑटोमेशन नसल्यास, त्या ओव्हरहेडचे व्यवस्थापन करणे कठीण होते.

आणखी एक व्यावहारिक समस्या म्हणजे बंडल आकार.. जर प्रत्येक मायक्रोफ्रंटएंडने स्वतःची React आणि शेअर्ड लायब्ररीची प्रत पाठवली तर एकूण डाउनलोड आकार वाढू शकतो, विशेषतः जेव्हा पेज रेंडर करण्यासाठी अनेक तुकड्यांची आवश्यकता असते. मॉड्यूल फेडरेशन (रनटाइमवर अवलंबित्वे शेअर करण्यासाठी) किंवा टीम्समध्ये मजबूतपणे संरेखित स्टॅक सारखे उपाय हे कमी करू शकतात.

अँगुलरसह मायक्रोफ्रंटएंड्स

अँगुलर अधिक मतप्रदर्शित मायक्रोफ्रंटएंड सेटअपसाठी उत्तम प्रकारे उपयुक्त आहे., विशेषतः जेव्हा तुम्ही मोनोरेपो आणि त्यांच्याभोवती असलेले टूलिंग वापरता (जसे की Nx). अँगुलर वर्कस्पेसेस प्रोजेक्ट्स आणि लायब्ररीमध्ये व्यवस्थित केल्या जातात, ज्यामुळे मोठ्या सोल्यूशनला अनेक अॅप्स आणि शेअर्ड लायब्ररीमध्ये विभाजित करणे स्वाभाविक होते.

अँगुलर १२ आणि वेबपॅक ५ पासून, मॉड्यूल फेडरेशन प्रथम श्रेणीचे नागरिक बनले आहे.. अँगुलर प्रोजेक्टला स्कीमॅटिक कमांड वापरून होस्ट किंवा रिमोट म्हणून कॉन्फिगर केले जाऊ शकते, आवश्यक वायरिंग अप केले जाऊ शकते webpack.config.js आणि तुमच्यासाठी बूटस्ट्रॅप लॉजिक.

या मॉडेलमध्ये, "होस्ट" अँगुलर अॅप शेल म्हणून काम करते जे नेव्हिगेशन, शेअर्ड स्टेट आणि डिपेंडन्सी शेअरिंगचे आयोजन करते. वैयक्तिक अँगुलर मायक्रोफ्रंटएंड्स (रिमोट्स) अँगुलर मॉड्यूल्स उघड करतात जे होस्ट मॉड्यूल फेडरेशनद्वारे गतिमानपणे लेझी-लोड करू शकतो.

नेहमीचे अँगुलर राउटिंग प्रिमिटिव्ह अजूनही लागू होतात. मायक्रोफ्रंटएंडमध्ये, तुम्ही वापरता RouterModule.forChild चाइल्ड रूट व्याख्यांसाठी जेणेकरून होस्ट एकमेव वापरणारा असेल forRoot. अशाप्रकारे, राउटर संघर्षांशिवाय अनेक अँगुलर अॅप्स एका एकत्रित URL स्पेसमध्ये एकत्र राहू शकतात.

सरावात मॉड्यूल फेडरेशन (कोनीय उदाहरण)

वेबपॅक मॉड्यूल फेडरेशन हे एक वेबपॅक ५ वैशिष्ट्य आहे जे रनटाइमवर एकाधिक बिल्डना कोड शेअर करण्याची परवानगी देते.. एक बिल्ड (होस्ट) इतर बिल्ड्स (रिमोट्स) द्वारे उघड केलेले मॉड्यूल्स एका लहान मॅनिफेस्ट फाइलद्वारे गतिमानपणे लोड करते, ज्याला सामान्यतः remoteEntry.js.

अँगुलरमध्ये तुम्ही हे खूप लवकर स्कॅफोल्ड करू शकता. उदाहरणार्थ, तुम्ही होस्ट अॅप तयार करू शकता (host-app) आणि नंतर सारखे स्कीमॅटिक चालवा ng add @angular-architects/module-federation --project host-app --port 4200. हे ModuleFederationPlugin कॉन्फिगरेशन, बूटस्ट्रॅपिंग फाइल्स आणि रनटाइम लॉजिक सेट करते.

त्यानंतर तुम्ही दोन रिमोट अँगुलर अ‍ॅप्स तयार करा: एक उत्पादन कॅटलॉगसाठी आणि एक शॉपिंग कार्टसाठी.. प्रत्येक अॅपला स्वतःचा पोर्ट मिळतो (उदा. ४२०१ साठी products-app, ४२०२ साठी cart-app) आणि त्याचे स्वतःचे मॉड्यूल फेडरेशन कॉन्फिगरेशन. मध्ये webpack.config.js तुम्ही वापरत असलेल्या प्रत्येक रिमोटचा exposes सारख्या की अंतर्गत मॉड्यूल (सामान्यत: मुख्य अ‍ॅप मॉड्यूल) प्रकाशित करण्यासाठी ./ProductsModule or ./CartModule.

होस्ट शेल नंतर असे मार्ग परिभाषित करते जे त्या रिमोट मॉड्यूल्सना आळशीपणे लोड करतात. द्वारे loadRemoteModule आरोग्यापासून @angular-architects/module-federation. उदाहरणार्थ, नेव्हिगेट करणे /products पासून गतिमान आयात सुरू करते http://localhost:4201/remoteEntry.js आणि भार ProductsModule; /cart कार्ट रिमोटसोबतही असेच करते.

कॅटलॉग मायक्रोफ्रंटएंडमध्ये तुमच्याकडे असू शकते ProductsComponent जे आयटमची एक सारणी देते, a वरून डेटा वाचणे PRODUCTS_CATALOG स्थिर आणि "कार्टमध्ये जोडा" बटण देत आहे. क्लिक केल्यावर, ते आयटममध्ये टिकून राहते localStorage "कार्ट" की अंतर्गत, उत्पादन आधीच अस्तित्वात असताना प्रमाण वाढवत.

नंतर कार्ट मायक्रोफ्रंटएंड त्याचमधून वाचतो localStorage की, उत्पादनाचे नाव, किंमत, प्रमाण आणि एकूण सारणी दर्शविते आणि "क्लीअर कार्ट" बटण देते जे स्टोरेज पुसते आणि त्याची अंतर्गत स्थिती रीसेट करते. घट्ट जोडणीशिवाय दोन स्वतंत्र अॅप्समध्ये स्थिती सामायिक करण्याचा हा एक सोपा परंतु स्पष्ट मार्ग आहे.

होस्ट शेल तयार करणे: लेआउट, होम आणि नेव्हिगेशन

मायक्रोफ्रंटएंड्समध्ये चांगल्या वापरकर्ता अनुभवासाठी एक मजबूत होस्ट शेल महत्त्वाचा आहे.. त्याच्याकडे सहसा ग्लोबल लेआउट (हेडर, फूटर, साइडबार), टॉप-लेव्हल रूटिंग आणि कधीकधी ग्लोबल स्टेट सारखी ऑथेंटिकेशन किंवा फीचर फ्लॅग असतात.

अँगुलर उदाहरणात, होस्ट a परिभाषित करतो LayoutComponent जे हेडर आणि नेस्टेड रेंडर करते router-outlet. हेडर स्वतःमध्ये राहतो HeaderModule आणि अँगुलरच्या माध्यमातून होम पेज, उत्पादन सूची आणि कार्टवर नेव्हिगेशन लिंक्स उघड करते routerLink. मार्ग मार्ग enum सारख्या मध्ये केंद्रीकृत केले जाऊ शकतात RoutesPath जादूच्या तारांपासून वाचण्यासाठी.

लेआउट राउटिंग मॉड्यूल एक मूळ मार्ग सेट करतो ज्यासह LayoutComponent त्याचा घटक म्हणून आणि यासाठी चाइल्ड रूट परिभाषित करते /home, /products आणि /cart. अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना /home मार्ग लोकल लोड करतो HomeModule; इतर वापरतात loadRemoteModule रन टाइमवर अँगुलर मायक्रोफ्रंटएंड्स खेचण्यासाठी.

यजमानाच्या आत, एक SharedModule पुन्हा वापरता येणारे बिल्डिंग ब्लॉक्स गोळा करू शकतो जसे की हेडर, लेआउट, सामान्य निर्देश आणि स्थिरांक. हे मॉड्यूल रूटमध्ये आयात केले जाऊ शकते AppModule सोबत AppRoutingModule, जे लेआउट राउटिंग कॉन्फिगरेशनकडे रिकामा मार्ग दर्शवते.

Next.js आणि मायक्रोफ्रंटएंड्स

Next.js, उत्पादन-श्रेणीतील प्रतिक्रिया फ्रेमवर्क म्हणून, मायक्रोफ्रंटएंड दृष्टिकोनासह देखील चांगले काम करते., विशेषतः वेबपॅक ५ स्वीकारल्यामुळे आणि म्हणूनच मॉड्यूल फेडरेशनला समर्थन मिळाल्यामुळे. SSR, वाढीव स्थिर पुनर्जन्म आणि राउटिंगवर त्याचे लक्ष केंद्रित केल्याने ते शेल, वैयक्तिक मायक्रोफ्रंटएंड्स किंवा दोन्हीसाठी एक चांगले उमेदवार बनते.

Next.js मध्ये मायक्रोफ्रंटएंड्स लागू करण्यासाठी तुम्ही सामान्यतः वेबपॅक स्तरावर मॉड्यूल फेडरेशन कॉन्फिगर करता., काही पृष्ठे किंवा घटक रिमोट म्हणून उघड करणे आणि होस्टकडून त्यांचा वापर करणे. जरी मॉड्यूल फेडरेशन हे "फक्त" एक जावास्क्रिप्ट बंडलर वैशिष्ट्य असले तरी, तुम्ही ते एक आर्किटेक्चरल पॅटर्न म्हणून विचार करू शकता: ते तुम्हाला वेळेपूर्वी सर्वकाही एकत्र न करता वेगवेगळ्या टीम्सच्या मालकीचे कोड गतिमानपणे लोड करू देते.

वेबपॅक ५ शिवाय असलेल्या Next.js च्या जुन्या आवृत्त्यांसाठी तुम्हाला बाह्य अडॅप्टरची आवश्यकता असेल. फेडरेशन सपोर्ट सक्षम करण्यासाठी. पुढील १०.२ पासून, वेबपॅक ५ सपोर्ट बिल्ट-इन आहे, जो सेटअप नाटकीयरित्या सुलभ करतो.

सिंगल-एसपीए आणि इतर मायक्रोफ्रंटएंड फ्रेमवर्क

सिंगल-एसपीए हा मायक्रोफ्रंटएंड्ससाठी आणखी एक सुप्रसिद्ध उपाय आहे, विशेषतः रिएक्ट इकोसिस्टममध्ये.. हे एकाच पृष्ठावर अनेक स्वतंत्र अॅप्स ऑर्केस्ट्रेट करण्यावर लक्ष केंद्रित करते, प्रत्येक अॅप्स सध्याच्या मार्गावर आधारित त्याच्या स्वतःच्या DOM नोडमध्ये माउंट केले जातात.

सिंगल-एसपीए सह तुमच्याकडे अनेक रिअॅक्ट अॅप्लिकेशन्स (किंवा रिअॅक्ट, व्ह्यू, अँगुलर मिक्स) एकत्र असू शकतात.. वापरकर्ता नेव्हिगेट करत असताना प्रत्येक मायक्रोफ्रंटएंड कधी बूटस्ट्रॅप करायचा, माउंट करायचा किंवा अनमाउंट करायचा हे फ्रेमवर्क हाताळते आणि तुम्ही ते तुमच्या राउटिंग स्ट्रॅटेजीमध्ये जोडता (उदाहरणार्थ, प्रत्येक फ्रॅगमेंटमध्ये रिएक्ट राउटरसह).

सिंगल-एसपीए आणि मॉड्यूल फेडरेशन दरम्यान निवड करताना, संघ अनेकदा त्यांच्या बंडलर/टूलिंग प्राधान्यांचा विचार करतात. मॉड्यूल फेडरेशन वेबपॅकसह खोलवर एकत्रित होते (आणि, वाढत्या प्रमाणात, Rspack किंवा रोलअप सारख्या पर्यायांसह ते समर्थन जोडतात). दुसरीकडे, सिंगल-एसपीए, बंडल शेअरिंगपेक्षा रनटाइम ऑर्केस्ट्रेशनबद्दल अधिक आहे, म्हणून तुम्ही ते इतर मार्गांनी कोड शेअरिंग हाताळताना वेगवेगळ्या बिल्ड टूल्ससह वापरू शकता.

मायक्रोफ्रंटएंड्सची उद्दिष्टे, वैशिष्ट्ये आणि फायदे

मायक्रोफ्रंटएंड्सचा मुख्य उद्देश म्हणजे समन्वय ओव्हरहेड अंतर्गत कोलमडून न पडता अनेक संघांमध्ये फ्रंटएंड विकासाचे प्रमाण वाढवणे.. सिंक्रोनाइझ केलेल्या रिलीझसह एका मोठ्या कोडबेसऐवजी, तुम्हाला लहान स्वतंत्रपणे तैनात करण्यायोग्य युनिट्स मिळतात.

मुख्य उद्दिष्टांमध्ये सहसा समाविष्ट असते अनेक संघांना समांतरपणे काम करण्यास सक्षम करणे, UI च्या वेगवेगळ्या भागांसाठी स्वतंत्र तैनाती समर्थित करणे, अर्थपूर्ण असलेल्या ठिकाणी वेगवेगळ्या तंत्रज्ञानाचा वापर करण्याची लवचिकता राखणे आणि प्रत्येक कोडबेसचा आकार आणि जटिलता कमी करून देखभालक्षमता सुधारणे.

अशा आर्किटेक्चरची विशिष्ट वैशिष्ट्ये म्हणजे शेअर्ड लायब्ररीद्वारे घटकांचा पुनर्वापर., अॅप्लिकेशन शेलद्वारे मॉड्यूलर इंटिग्रेशन, प्रत्येक मायक्रोफ्रंटएंडसाठी स्वतंत्र पाइपलाइन, सीडीएन आणि कॅशिंगद्वारे परफॉर्मन्स ऑप्टिमायझेशन, सेंट्रलाइज्ड सिक्युरिटी हँडलिंग आणि मजबूत निरीक्षणक्षमता.

व्यवसायाच्या दृष्टिकोनातून, फायदे लक्षणीय आहेत: अधिक टीम्ससह विकासाचे प्रमाण चांगले होते, अपयश चांगले वेगळे केले जातात, प्रत्येक डोमेनसाठी वैशिष्ट्ये रोल आउट किंवा रोल बॅक करता येतात आणि संपूर्ण अॅप पुन्हा लिहिण्याऐवजी एका वेळी एक स्लाइस बदलून लेगसी फ्रंटएंड स्टॅक हळूहळू स्थलांतरित केले जाऊ शकतात.

मायक्रोफ्रंटएंड आर्किटेक्चरमधील प्रमुख घटक

अंमलबजावणी वेगवेगळी असली तरी, बहुतेक मायक्रोफ्रंटएंड आर्किटेक्चर्समध्ये काही स्ट्रक्चरल घटक असतात. जे सर्वकाही सुसंगत ठेवते.

अ‍ॅप्लिकेशन शेल (किंवा कंटेनर) हा आधारस्तंभ आहे. बाह्य लेआउट, जागतिक नेव्हिगेशन, प्रमाणीकरण, कधीकधी जागतिक स्थिती आणि मायक्रोफ्रंटएंड्स लोड किंवा अनलोड करण्यासाठी लॉजिक हे त्याचे मालकीचे असते. ब्राउझर-आधारित सेटअपमध्ये, हे पृष्ठ आहे जे इतर सर्व बंडलमध्ये खेचते.

प्रत्येक मायक्रोफ्रंटएंड हा एक स्वयंपूर्ण मॉड्यूल आहे जो विशिष्ट क्षमता लागू करतो, जसे की उत्पादन कॅटलॉग, शॉपिंग कार्ट, वापरकर्ता प्रोफाइल किंवा अ‍ॅडमिन पॅनेल. हे एकात्मिक पृष्ठभाग (रूट्स, कस्टम एलिमेंट्स, मॉड्यूल फेडरेशन रिमोट्स) उघड करते आणि उर्वरित सिस्टमपासून अंतर्गत तपशील लपवते.

क्रॉस-मायक्रोफ्रंटएंड कम्युनिकेशनसाठी अनेकदा इव्हेंट बस किंवा मेसेज सिस्टम असते.. हे DOM इव्हेंट्स, सेंट्रलाइज्ड रेडक्स स्टोअर किंवा कस्टम मेसेज ब्रोकरवर एक साधे अ‍ॅबस्ट्रॅक्शन असू शकते. ध्येय म्हणजे प्रकाशन/सदस्यता शब्दार्थ वेगळे करणे: मायक्रोफ्रंटएंड इव्हेंट्स कोण हाताळते हे न कळता उत्सर्जित करतो.

शेअर्ड लायब्ररीमध्ये पुन्हा वापरता येणारे UI घटक, उपयुक्तता, डिझाइन टोकन आणि सामान्य क्लायंट असतात.. मोनोरेपो सेटअपमध्ये Nx सारखी साधने येथे चमकतात, ज्यामुळे तुम्हाला अनेक अॅप्सद्वारे वापरल्या जाणाऱ्या शेअर्ड पॅकेजेसची अंमलबजावणी केलेल्या सीमा आणि सुसंगत आवृत्त्यांसह व्याख्या करता येते.

निरीक्षणक्षमता संग्राहक आणि साधने (उदाहरणार्थ ओपनटेलिमेट्री वापरणे) सर्व मायक्रोफ्रंटएंड्समधील लॉग, मेट्रिक्स आणि ट्रेस एकत्रित करते, ज्यामुळे अनेक तुकड्या किंवा सेवांमध्ये पसरलेल्या समस्यांचे निदान करणे शक्य होते.

डिलिव्हरीच्या बाजूने CDN चित्र पूर्ण करतात., जेएस बंडल, सीएसएस आणि वापरकर्त्यांच्या जवळील प्रतिमा यासारख्या स्थिर मालमत्ता कॅश करणे, विलंब कमी करणे आणि मूळ सर्व्हर ऑफलोड करणे. मायक्रोफ्रंटएंड सेटअपमध्ये, तुम्ही अनेकदा प्रत्येक तुकड्याच्या मालमत्तेला स्वतंत्र कॅशिंग आणि रोलआउटसाठी त्याच्या स्वतःच्या सीडीएन मार्गावर होस्ट करता.

मायक्रोफ्रंटएंड्ससाठी आर्किटेक्चर आणि डिझाइन पॅटर्न

मायक्रोफ्रंटएंड्सना विशेषतः लागू होणाऱ्या नमुन्यांचा एक समृद्ध कॅटलॉग आहे., सामान्यतः तुम्ही त्यांना कसे तयार करता, तैनात करता आणि कनेक्ट करता यावरून परिभाषित केले जाते.

घटक-आधारित रचना म्हणजे वेब घटक किंवा तत्सम प्राइमिटिव्ह्जमधून UI तयार करणे.. प्रत्येक घटकाची एकच जबाबदारी असते, स्पष्ट इनपुट आणि आउटपुट असतात आणि ते स्वतंत्रपणे तपासले जाऊ शकतात. उच्च-स्तरीय रचना स्तर (जसे की शेल किंवा ऑर्केस्ट्रेशन फ्रेमवर्क) त्या घटकांना पूर्ण पृष्ठांमध्ये व्यवस्थित करतो.

फेडरेशन पॅटर्नमध्ये संपूर्ण अनुप्रयोग स्वायत्ततेवर भर दिला जातो.. प्रत्येक मायक्रोफ्रंटएंड हा एक स्वतंत्र अॅप आहे ज्याचे स्वतःचे जीवनचक्र आणि टीम आहे; शेल किंवा एपीआय गेटवे फक्त विनंत्या/डेटा योग्य तुकड्यावर पाठवतो. संवाद चांगल्या प्रकारे परिभाषित केलेल्या REST एपीआय किंवा इव्हेंटद्वारे होतो.

अ‍ॅप्लिकेशन शेल पॅटर्न हा प्रभावीपणे "होस्ट" दृष्टिकोन आहे.. शेल मायक्रोफ्रंटएंड्स लोड करते, नेव्हिगेशन आणि सुरक्षितता सारख्या क्रॉस-कटिंग समस्या हाताळते आणि एक सुसंगत लूक आणि फील सुनिश्चित करते. मॉड्यूल फेडरेशन किंवा सिंगल-एसपीए आधारित सेटअपमध्ये हे खूप सामान्य आहे.

एपीआय गेटवे आणि बॅकएंड-फॉर-फ्रंटेंड (बीएफएफ) पॅटर्न सर्व्हर साइडवर लक्ष केंद्रित करतात.. एक API गेटवे अनेक बॅकएंड सेवा, राउटिंग राउटिंग राउटिंग आणि सुरक्षा लागू करण्याच्या समोर बसतो. एक BFF पुढे जातो: प्रत्येक फ्रंटएंड (वेब, मोबाइल, IoT) त्याच्या गरजांनुसार स्वतःचा समर्पित बॅकएंड तयार करू शकतो.

वितरित डेटा स्टोरेज पॅटर्न हे मान्य करतात की वेगवेगळे मायक्रोफ्रंटएंड त्यांचे स्वतःचे डेटा स्रोत व्यवस्थापित करू शकतात. किंवा कॅशे. ब्राउझरमध्ये याचा अर्थ अनेकदा स्वतंत्र लोकलस्टोरेज की, इंडेक्स्डडीबी डेटाबेस किंवा इन-मेमरी स्टोअर्स वापरणे असा होतो, तर बॅकएंडमध्ये याचा अर्थ प्रत्येक मायक्रोसर्व्हिससाठी वेगळे डेटाबेस वापरणे असा होतो.

निरीक्षणक्षमता, स्वतंत्र तैनाती, क्षैतिज स्केलेबिलिटी आणि सुरक्षा नमुने ऑपरेशनल समस्यांचे निराकरण: प्रत्येक तुकड्याचे निरीक्षण कसे करावे, जागतिक आउटेजशिवाय ते कसे तैनात करावे, त्यांना लोड अंतर्गत कसे मोजावे आणि प्रमाणीकरण/अधिकृतता सातत्याने कशी लागू करावी.

राउटिंग रचना आणि आळशी लोडिंग पॅटर्न हे UX आणि कामगिरीचे केंद्रबिंदू आहेत.. मास्टर राउटर ठरवतो की कोणता मायक्रोफ्रंटएंड कोणता मार्ग हाताळतो आणि प्रत्येक मायक्रोफ्रंटएंडचा स्वतःचा अंतर्गत राउटर असतो. आळशी लोडिंगमुळे तुम्ही फक्त सध्याच्या रूटसाठी आवश्यक असलेल्या तुकड्यांसाठी कोड डाउनलोड करता.

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

मायक्रोफ्रंटएंड्स कधी वापरायचे (आणि कधी नाही)

चांगल्या प्रकारे परिभाषित कार्यात्मक डोमेन असलेल्या मोठ्या, जटिल अनुप्रयोगांमध्ये मायक्रोफ्रंटएंड चमकतात.. ई-कॉमर्स प्लॅटफॉर्म, एंटरप्राइझ मॅनेजमेंट सिस्टम, म्युनिसिपल पोर्टल, एज्युकेशन प्लॅटफॉर्म, मोठे हेल्थ पोर्टल किंवा वेगवेगळ्या कार्यात्मक क्षेत्रांवर काम करणाऱ्या अनेक टीम्ससह कोणतेही उत्पादन विचारात घ्या.

जेव्हा तुमच्याकडे अनेक टीम्स समांतर काम करत असतात तेव्हा ते विशेषतः उपयुक्त ठरतात. ज्यांना तंत्रज्ञानाच्या निवडी, रिलीज सायकल आणि प्राधान्यक्रमांमध्ये स्वायत्तता आवश्यक आहे, किंवा जेव्हा तुम्ही हळूहळू लेगसी फ्रंटएंडचे आधुनिकीकरण करत असाल आणि पूर्ण पुनर्लेखन परवडत नाही. तुम्ही एका वेळी एक क्षेत्र नवीन मायक्रोफ्रंटएंडमध्ये कोरू शकता आणि ते जुन्या शेलसह एकत्रित करू शकता.

जेव्हा अ‍ॅपच्या वेगवेगळ्या भागांना वेगवेगळ्या पद्धतीने स्केल करण्याची आवश्यकता असते तेव्हा ते देखील मदत करतात.. लॉगिन किंवा चेकआउट पेजला अॅडमिन कॉन्फिगरेशन स्क्रीनपेक्षा जास्त ट्रॅफिक मिळू शकतो; त्या स्लाइस स्वतंत्रपणे स्केल केल्याने पायाभूत सुविधांचा खर्च खूप वाचू शकतो.

तथापि, मायक्रोफ्रंटएंड्स हे मोफत जेवण नाही.. ते वास्तुशास्त्रीय गुंतागुंत वाढवतात, UX आणि सामायिक करारांवर मजबूत समन्वय आवश्यक असतो आणि नवीन अपयश मोड सादर करतात (उदाहरणार्थ, एक तुकडा लोड होत नाही). एकाच टीमसह लहान किंवा मध्यम अॅप्ससाठी, सु-संरचित मोनोलिथ बहुतेकदा सोपे आणि अधिक किफायतशीर असते.

संघांनी "चौकट अराजकतेपासून" देखील सावध असले पाहिजे.. तांत्रिकदृष्ट्या प्रत्येक मायक्रोफ्रंटएंडसाठी पूर्णपणे भिन्न स्टॅक वापरणे शक्य असले तरी, फ्रेमवर्कचे अनियंत्रित मिश्रण भरती, टूलिंग आणि कोड शेअरिंगला कठीण बनवते. संरेखनाची वाजवी पातळी (उदाहरणार्थ, "आम्ही रिएक्ट-फर्स्ट शॉप आहोत, परंतु आम्ही विशिष्ट डोमेनसाठी अँगुलरला परवानगी देतो") सहसा दीर्घकाळात चांगले कार्य करते.

मायक्रोफ्रंटएंड्स ब्राउझरमध्ये मायक्रोसर्व्हिसेस मानसिकतेचा विस्तार करतात, ज्यामुळे टीम्सना मोठ्या फ्रंटएंड्सना स्वायत्त, डोमेन-ओरिएंटेड तुकड्यांमध्ये विभागण्याचा मार्ग मिळतो जे अॅप्लिकेशन शेल, शेअर्ड लायब्ररी, मॉड्यूल फेडरेशन, वेब कंपोनेंट्स किंवा सिंगल-एसपीए सारख्या ऑर्केस्ट्रेशन फ्रेमवर्कद्वारे एकत्रित केल्यावर एकसंध वापरकर्ता अनुभव तयार करताना स्वतंत्रपणे विकसित, तैनात आणि स्केल करू शकतात.