نقاط القوة والفوائد من Micro Frontends

نشرت: 2022-03-11

تعد بنية الواجهة الأمامية المصغرة أسلوب تصميم يتم فيه تحلل تطبيق الواجهة الأمامية إلى "تطبيقات صغيرة" فردية وشبه مستقلة تعمل معًا بشكل غير محكم. مفهوم الواجهة الأمامية المصغرة مستوحى بشكل غامض من الخدمات المصغرة وسميت باسمها.

تشمل مزايا نمط الواجهة المصغرة ما يلي:

  1. قد تكون هياكل الواجهات الأمامية الدقيقة أبسط ، وبالتالي يسهل التفكير فيها وإدارتها.
  2. يمكن لفرق التطوير المستقلة التعاون في تطبيق الواجهة الأمامية بسهولة أكبر.
  3. يمكنهم توفير وسيلة للانتقال من تطبيق "قديم" من خلال تشغيل تطبيق "جديد" جنبًا إلى جنب معه.

على الرغم من أن الواجهات الأمامية الصغيرة قد حظيت بالكثير من الاهتمام مؤخرًا ، إلا أنه حتى الآن لا يوجد تنفيذ مهيمن واحد ولا يوجد إطار عمل مصغر واضح "أفضل" للواجهة الأمامية. في الواقع ، هناك مجموعة متنوعة من الأساليب اعتمادًا على الأهداف والمتطلبات. انظر الببليوغرافيا لبعض التطبيقات المعروفة.

في هذه المقالة ، سوف نتخطى الكثير من نظرية الواجهات الدقيقة. إليك ما لن نغطيه:

  • "تقسيم" أحد التطبيقات إلى تطبيقات دقيقة
  • مشكلات النشر ، بما في ذلك كيفية ملاءمة الواجهات الأمامية الصغيرة في نموذج CI / CD
  • اختبارات
  • ما إذا كان يجب أن تكون التطبيقات المصغرة في محاذاة واحد لواحد مع الخدمات المصغرة على الواجهة الخلفية
  • انتقادات لمفهوم الواجهة الدقيقة
  • الفرق بين الواجهات الصغيرة والبنية المكونة القديمة البسيطة

بدلاً من ذلك ، سنقدم برنامجًا تعليميًا صغيرًا للواجهة الأمامية يركز على التنفيذ الملموس ، ويسلط الضوء على المشكلات المهمة في بنية الواجهة الأمامية الصغيرة والحلول الممكنة لها.

تطبيقنا يسمى Yumcha. المعنى الحرفي لـ "yum cha" في اللغة الكانتونية هو "شرب الشاي" ، لكن معناها اليومي هو "الخروج من أجل ديم سوم". تكمن الفكرة هنا في أن التطبيقات الدقيقة الفردية داخل تطبيق ماكرو (كما سنسمي التطبيق المكون من المستوى الأعلى) تشبه السلال المختلفة للأجزاء ذات الحجم الصغير التي يتم إخراجها في غداء خافت.

توضيح نظرة عامة على مثال لتطبيق يستند إلى الواجهة الأمامية المصغرة كما هو موضح أعلاه.

سنشير أحيانًا إلى Yumcha على أنه "إطار عمل مصغر للواجهة الأمامية". في عالم اليوم ، يُستخدم مصطلح "framework" عادةً للإشارة إلى Angular أو React أو Vue.js أو غيرها من التركيبات الفوقية المماثلة لتطبيقات الويب. نحن لا نتحدث عن إطار بهذا المعنى على الإطلاق. نحن نطلق على Yumcha إطار عمل فقط من أجل الراحة: إنه في الواقع أكثر من مجموعة من الأدوات وبضع طبقات رقيقة لبناء تطبيقات تعتمد على الواجهة الأمامية الصغيرة.

الخطوات الأولى للبرنامج التعليمي المصغر للواجهة الأمامية: ترميز تطبيق مكون

دعونا نتعمق بالتفكير في كيفية تحديد ماكرو والتطبيقات الدقيقة التي تتكون منه. لطالما كان الترميز في قلب الويب. لذلك ، سيتم تحديد تطبيق الماكرو الخاص بنا بشيء أكثر تعقيدًا من هذا الترميز:

 <html> <head> <script src="/yumcha.js"></script> </head> <body> <h1>Hello, micro-frontend app.</h1> <!-- HERE ARE THE MICROAPPS! --> <yumcha-portal name="microapp1" src="https://microapp1.example.com"></yumcha-portal> <yumcha-portal name="microapp2" src="https://microapp2.example.com"></yumcha-portal> </body> </html>

يمنحنا تحديد تطبيق الماكرو الخاص بنا باستخدام الترميز وصولاً كاملاً إلى قوة HTML و CSS لتخطيط تطبيقاتنا المصغرة وإدارتها. على سبيل المثال ، يمكن أن يجلس أحد التطبيقات الصغيرة فوق تطبيق آخر ، أو على جانبه ، أو أن يكون في زاوية الصفحة ، أو يكون في أحد أجزاء الأكورديون ، أو يظل مخفيًا حتى يحدث شيء ما ، أو يظل في الخلفية بشكل دائم .

لقد قمنا بتسمية العنصر المخصص المستخدم في التطبيقات المصغرة <yumcha-portal> لأن "portal" مصطلح واعد للتطبيقات الدقيقة المستخدمة في اقتراح البوابة ، وهي محاولة مبكرة لتعريف عنصر HTML قياسي للاستخدام في الواجهات الأمامية المصغرة.

تنفيذ العنصر المخصص <yumcha-portal>

كيف يجب أن نطبق <yumcha-portal> ؟ نظرًا لأنه عنصر مخصص ، كمكون ويب بالطبع! يمكننا الاختيار من بين عدد من المتنافسين الأقوياء لكتابة وتجميع مكونات الويب المصغرة للواجهة الأمامية ؛ هنا سوف نستخدم LitElement ، أحدث نسخة من مشروع البوليمر. يدعم LitElement السكر النحوي المستند إلى TypeScript ، والذي يتعامل مع معظم العناصر المعيارية المخصصة لنا. لإتاحة <yumcha-portal> ، يتعين علينا تضمين الكود ذي الصلة باعتباره <script> ، كما فعلنا أعلاه.

ولكن ماذا تفعل <yumcha-portal> في الواقع؟ سيكون التقريب الأول هو إنشاء إطار iframe بالمصدر المحدد:

 render() { return html`<iframe src=${this.src}></iframe>`; }

... حيث يكون render هو خطاف العرض القياسي LitElement ، باستخدام نموذج حرفي بعلامات html . قد يكون هذا الحد الأدنى من الوظائف كافيًا تقريبًا لبعض حالات الاستخدام التافهة.

تضمين Microapps في iframe s

iframe s هي عنصر HTML الذي يحب الجميع أن يكرهه ، لكنها في الواقع توفر سلوكًا مفيدًا للغاية في وضع الحماية. ومع ذلك ، لا تزال هناك قائمة طويلة من المشكلات التي يجب أن تكون على دراية بها عند استخدام iframe ، مع تأثير محتمل على سلوك ووظائف تطبيقنا:

  • أولاً ، تتمتع iframe بمراوغات معروفة من حيث حجمها وطريقة عرضها.
  • سيتم بالطبع عزل CSS تمامًا عن إطار iframe ، للأفضل أو للأسوأ.
  • سيعمل زر "رجوع" بالمتصفح بشكل معقول ، على الرغم من أن حالة التنقل الحالية iframe لن تنعكس في عنوان URL للصفحة ، لذلك لم نتمكن من قص ولصق عناوين URL للوصول إلى نفس حالة التطبيق المكون ، ولا رابط عميق لهم.
  • قد يحتاج الاتصال بإطار iframe من الخارج ، اعتمادًا على إعداد CORS الخاص بنا ، إلى المرور عبر بروتوكول postMessage .
  • يجب إجراء الترتيبات للمصادقة عبر حدود iframe .
  • قد تتعثر بعض برامج قراءة الشاشة عند حدود iframe أو تحتاج إلى iframe للحصول على عنوان يمكنهم الإعلان عنه للمستخدم.

يمكن تجنب بعض هذه المشكلات أو التخفيف من حدتها من خلال عدم استخدام iframe ، وهو بديل نناقشه لاحقًا في المقالة.

على الجانب الإيجابي ، سيكون iframe Content-Security-Policy (CSP) المستقلة الخاصة به. أيضًا ، إذا كان التطبيق المصغر الذي يشير إليه iframe يستخدم عامل خدمة أو ينفذ عرضًا من جانب الخادم ، فسيعمل كل شيء كما هو متوقع. يمكننا أيضًا تحديد خيارات وضع الحماية المختلفة لإطار iframe للحد من إمكانياته ، مثل القدرة على الانتقال إلى الإطار العلوي.

شحنت بعض المتصفحات أو تخطط لشحن سمة loading=lazy لـ iframe s ، والتي تؤجل التحميل أسفل الجزء المرئي من iframe حتى يقوم المستخدم بالتمرير بالقرب منها ، ولكن هذا لا يوفر تحكمًا دقيقًا في التحميل البطيء الذي نحن نريد.

تكمن المشكلة الحقيقية في iframe s في أن محتوى iframe سيتطلب عدة طلبات شبكة لاستردادها. يتم استلام index.html ذي المستوى الأعلى ، وتحميل البرامج النصية الخاصة به ، وتحليل HTML الخاص به - ولكن بعد ذلك يجب على المستعرض بدء طلب آخر لـ iframe HTML ، والانتظار لاستلامه ، وتحليل البرامج النصية الخاصة به وتحميلها ، وعرض محتويات iframe . في كثير من الحالات ، لا يزال يتعين على JavaScript في iframe الدوران ، وإجراء مكالمات API الخاصة به ، وإظهار البيانات ذات المعنى فقط بعد عودة استدعاءات واجهة برمجة التطبيقات هذه ومعالجة البيانات للعرض.

من المحتمل أن يؤدي هذا إلى تأخيرات غير مرغوب فيها وعرض القطع الأثرية ، خاصةً عند تضمين العديد من التطبيقات الدقيقة. إذا كان تطبيق iframe يطبق SSR ، فسيساعد ذلك ولكنه لا يتجنب ضرورة القيام برحلات إضافية ذهابًا وإيابًا.

لذا فإن أحد التحديات الرئيسية التي نواجهها في تصميم تنفيذ بوابتنا هو كيفية التعامل مع هذه المشكلة ذهابًا وإيابًا. هدفنا هو أن يقوم طلب شبكة واحد بإسقاط الصفحة بأكملها بكل تطبيقاتها الدقيقة ، بما في ذلك أي محتوى يمكن لكل منهم ملؤه مسبقًا. يكمن حل هذه المشكلة في خادم Yumcha.

خادم Yumcha

أحد العناصر الأساسية في حل الواجهة المصغرة المقدم هنا هو إعداد خادم مخصص للتعامل مع تكوين التطبيقات المصغرة. يطلب وكلاء الخادم هذا إلى الخوادم حيث يتم استضافة كل تطبيق صغير. منحت ، سوف يتطلب الأمر بعض الجهد لإعداد وإدارة هذا الخادم. تحاول بعض مناهج الواجهات المصغرة (على سبيل المثال ، المنتجع الصحي الفردي) الاستغناء عن الحاجة إلى مثل هذه الإعدادات الخاصة للخادم ، باسم سهولة النشر والتكوين.

ومع ذلك ، فإن تكلفة إعداد هذا الوكيل العكسي يتم تعويضها أكثر من خلال الفوائد التي نكتسبها ؛ في الواقع ، هناك سلوكيات مهمة للتطبيقات المصغرة القائمة على الواجهة الأمامية والتي لا يمكننا تحقيقها بدونها. هناك العديد من البدائل التجارية والمجانية لإنشاء مثل هذا الوكيل العكسي.

يقوم الوكيل العكسي ، بالإضافة إلى توجيه طلبات التطبيق المصغر إلى الخادم المناسب ، أيضًا بتوجيه طلبات الماكرو إلى خادم ماكرو. يقوم هذا الخادم بإعداد HTML للتطبيق المؤلف بطريقة خاصة. عند تلقي طلب index.html من المتصفح عن طريق الخادم الوكيل على عنوان URL مثل http://macroapp.example.com ، فإنه يسترد index.html ثم يخضعه لعملية تحويل بسيطة ولكنها حاسمة قبل العودة هو - هي.

على وجه التحديد ، يتم تحليل HTML <yumcha-portal> ، والتي يمكن إجراؤها بسهولة باستخدام أحد محللي HTML الأكفاء والمتاحين في نظام Node.js البيئي. باستخدام السمة src إلى <yumcha-portal> ، يتم الاتصال بالخادم الذي يقوم بتشغيل التطبيق المصغر ويتم استرداد index.html الخاص به - بما في ذلك المحتوى المعروض من جانب الخادم ، إن وجد. يتم إدراج النتيجة في استجابة HTML كعلامة <script> أو <template> ، حتى لا يتم تنفيذها بواسطة المتصفح.

رسم توضيحي لهندسة خادم Yumcha. يتصل المتصفح بالوكيل العكسي ، والذي بدوره يتصل بتطبيق الماكرو وكل من التطبيقات الدقيقة. تعمل خطوة تطبيق الماكرو على تحويل ملف index.html الرئيسي للتطبيق وتعبئته مسبقًا.

تشمل مزايا هذا الإعداد ، أولاً وقبل كل شيء ، أنه في أول طلب لـ index.html للصفحة المكونة ، يمكن للخادم استرداد الصفحات الفردية من خوادم microapp الفردية بالكامل - بما في ذلك المحتوى المقدم من SSR ، إذا أي - وتسليم صفحة واحدة كاملة إلى المتصفح ، بما في ذلك المحتوى الذي يمكن استخدامه لملء إطار iframe بدون جولات إضافية للخادم ذهابًا وإيابًا (باستخدام سمة srcdoc غير المستخدمة). يضمن الخادم الوكيل أيضًا إخفاء أي تفاصيل عن مكان تقديم التطبيقات الدقيقة عن أعين المتطفلين. أخيرًا ، فإنه يبسط مشكلات CORS ، نظرًا لأن جميع طلبات التطبيق يتم إجراؤها على نفس الأصل.

بالعودة إلى العميل ، يتم إنشاء مثيل لعلامة <yumcha-portal> والعثور على المحتوى حيث تم وضعه في مستند الاستجابة بواسطة الخادم ، وفي الوقت المناسب يعرض إطار iframe ويعين المحتوى إلى سمة srcdoc الخاصة به. إذا لم نستخدم iframe s (انظر أدناه) ، فسيتم إدراج المحتوى المقابل <yumcha-portal> إما في ظل DOM الخاص بالعنصر المخصص ، إذا كنا نستخدم ذلك ، أو مضمّنًا مباشرةً في المستند.

في هذه المرحلة ، لدينا بالفعل تطبيق قائم على الواجهة الأمامية الصغيرة يعمل جزئيًا.

هذا مجرد غيض من فيض من حيث الوظائف المثيرة للاهتمام لخادم Yumcha. على سبيل المثال ، نرغب في إضافة ميزات للتحكم في كيفية التعامل مع استجابات خطأ HTTP من خوادم microapp ، أو كيفية التعامل مع تطبيقات microapp التي تستجيب ببطء شديد - لا نريد الانتظار إلى الأبد لخدمة الصفحة إذا لم يكن هناك تطبيق صغير واحد يستجيب! هذه وغيرها من المواضيع التي سنتركها لمنشور آخر.

يمكن بسهولة تنفيذ منطق التحويل Yumcha macroapp index.html بطريقة دالة lambda بدون خادم ، أو كبرنامج وسيط لأطر عمل الخادم مثل Express أو Koa.

أداة تحكم Microapp القائمة على كعب الروتين

بالعودة إلى جانب العميل ، هناك جانب آخر لكيفية تنفيذنا للتطبيقات المصغرة وهو أمر مهم لتحقيق الكفاءة ، والتحميل البطيء ، والعرض الخالي من الرسائل غير المرغوب فيها. يمكننا إنشاء علامة iframe لكل تطبيق مصغر ، إما باستخدام سمة src - التي تقدم طلب شبكة آخر - أو باستخدام سمة srcdoc المملوءة بالمحتوى الذي يملأه الخادم لنا. ولكن في كلتا الحالتين ، ستبدأ الشفرة الموجودة في iframe هذا على الفور ، بما في ذلك تحميل جميع البرامج النصية وعلامات الارتباط ، و bootstrapping ، وأي استدعاءات أولية لواجهة برمجة التطبيقات ومعالجة البيانات ذات الصلة - حتى لو لم يصل المستخدم مطلقًا إلى التطبيق المصغر المعني.

يتمثل حلنا لهذه المشكلة في تمثيل التطبيقات الدقيقة في الصفحة مبدئيًا على أنها أجزاء صغيرة غير نشطة ، والتي يمكن تنشيطها بعد ذلك. يمكن أن يكون التنشيط مدفوعًا إما بمنطقة microapp التي تظهر ، أو باستخدام IntersectionObserver API ، أو بشكل أكثر شيوعًا عن طريق الإشعارات المسبقة المرسلة من الخارج. بالطبع ، يمكننا أيضًا تحديد تنشيط التطبيق المصغر على الفور.

على أي حال ، عندما يتم تنشيط التطبيق المصغر وفقط عند تنشيطه ، يتم عرض إطار iframe بالفعل ويتم تحميل الكود الخاص به وتنفيذه. فيما يتعلق بتنفيذنا باستخدام LitElement ، وبافتراض أن حالة التنشيط يتم تمثيلها بواسطة متغير مثيل activated ، سيكون لدينا شيء مثل:

 render() { if (!this.activated) return html`{this.placeholder}`; else return html` <iframe srcdoc="${this.content}" @load="${this.markLoaded}"></iframe>`; }

اتصال Inter-microapp

على الرغم من أن microapps التي تُكوِّن تطبيق ماكرو مرتبطة بحكم تعريفها بشكل فضفاض ، إلا أنها لا تزال بحاجة إلى أن تكون قادرة على التواصل مع بعضها البعض. على سبيل المثال ، سيحتاج تطبيق microapp للتنقل إلى إرسال إشعار يفيد بأنه يجب تنشيط بعض التطبيقات الدقيقة الأخرى التي حددها المستخدم للتو ، ويحتاج التطبيق المراد تنشيطه إلى تلقي مثل هذه الإشعارات.

تماشيًا مع عقلية الحد الأدنى لدينا ، نريد تجنب إدخال الكثير من آلات تمرير الرسائل. بدلاً من ذلك ، بروح مكونات الويب ، سنستخدم أحداث DOM. نحن نقدم واجهة برمجة تطبيقات بث تافهة تقوم بإخطار جميع الأجزاء الجذرية لحدث وشيك مسبقًا ، وتنتظر أي طلب يتم تنشيطه لتنشيط نوع الحدث هذا ، ثم يرسل الحدث مقابل المستند ، حيث يمكن لأي تطبيق ميكرو أن يستمع إليه هو - هي. نظرًا لأن جميع iframe الخاصة بنا من نفس الأصل ، يمكننا الوصول من iframe إلى الصفحة والعكس بالعكس للعثور على العناصر التي يتم إطلاق الأحداث وفقًا لها.

التوجيه

في هذا اليوم وهذا العصر ، نتوقع جميعًا أن يمثل شريط URL في SPAs حالة عرض التطبيق ، حتى نتمكن من قصها ولصقها وإرسالها بالبريد والنص والارتباط بها للانتقال مباشرةً إلى صفحة داخل التطبيق. ومع ذلك ، في تطبيق micro-frontend ، تكون حالة التطبيق في الواقع مجموعة من الحالات ، واحدة لكل تطبيق microapp. كيف يمكننا تمثيل هذا والتحكم فيه؟

يكمن الحل في ترميز كل حالة من حالات التطبيق المصغر في عنوان URL مركب واحد واستخدام جهاز توجيه ماكرو صغير يعرف كيفية تجميع عنوان URL المركب معًا واختياره بشكل منفصل. لسوء الحظ ، يتطلب هذا منطقًا خاصًا بـ Yumcha في كل تطبيق مصغر: لتلقي الرسائل من جهاز توجيه macapp وتحديث حالة التطبيق المصغر ، وعلى العكس من ذلك لإعلام موجه تطبيقات الماكرو بالتغييرات في تلك الحالة حتى يمكن تحديث عنوان URL المركب. على سبيل المثال ، يمكن للمرء أن يتخيل YumchaLocationStrategy لـ Angular ، أو عنصر <YumchaRouter> لـ React.

عنوان URL مركب يمثل حالة تطبيق ماكرو. تقوم سلسلة الاستعلام الخاصة بها بترميز سلسلتي استعلام منفصلتين (مشفرة بشكل مزدوج) والتي يتم بعد ذلك تمريرها إلى التطبيقات الدقيقة التي يتم تحديد معرفاتها كمفاتيح لها.

الحالة غير iframe

كما ذكرنا أعلاه ، فإن استضافة تطبيقات دقيقة في iframe لها بعض الجوانب السلبية. هناك بديلان: قم بتضمينهما مباشرةً في السطر في HTML للصفحة ، أو ضعهما في الظل DOM. يعكس كلا الخيارين إيجابيات وسلبيات iframe إلى حد ما ، ولكن بطرق مختلفة في بعض الأحيان.

على سبيل المثال ، يجب دمج سياسات CSP الفردية للتطبيقات الصغيرة بطريقة ما. يجب أن تعمل التقنيات المساعدة ، مثل برامج قراءة الشاشة ، بشكل أفضل من استخدام iframe ، على افتراض أنها تدعم ظل DOM (الذي لا يعمل جميعها حتى الآن). يجب أن يكون من السهل ترتيب تسجيل عمال خدمة التطبيق المصغر باستخدام مفهوم عامل الخدمة "النطاق" ، على الرغم من أن التطبيق يجب أن يضمن تسجيل عامل الخدمة تحت اسم التطبيق ، وليس "/" . لا تنطبق أي من مشكلات التخطيط المرتبطة iframe على أساليب DOM المضمنة أو الظل.

ومع ذلك ، من المحتمل أن تكون التطبيقات التي تم إنشاؤها باستخدام أطر عمل مثل Angular و React غير سعيدة بالعيش المضمّن أو في ظل DOM. بالنسبة لهؤلاء ، من المحتمل أن نرغب في استخدام iframe s.

تختلف أساليب DOM المضمنة والظل عندما يتعلق الأمر بـ CSS. سيتم تغليف CSS بشكل نظيف في Shadow DOM. إذا أردنا لسبب ما المشاركة خارج CSS مع Shadow DOM ، فسيتعين علينا استخدام أوراق أنماط قابلة للإنشاء أو شيء مشابه. باستخدام تطبيقات دقيقة مضمنة ، ستتم مشاركة جميع CSS في جميع أنحاء الصفحة.

في النهاية ، يعد تنفيذ منطق تطبيقات DOM المضمنة والظل في <yumcha-portal> . نقوم باسترداد محتوى تطبيق ميكرو معين من حيث تم إدراجه في الصفحة بواسطة منطق الخادم كعنصر <template> HTML ، ثم استنساخه ، ثم إلحاقه بما يسميه renderRoot ، والذي يكون عادةً عنصر ظل DOM للعنصر ، ولكن يمكنه يتم أيضًا تعيينه على العنصر نفسه ( this ) للحالة المضمنة (غير الظل DOM).

لكن انتظر! المحتوى الذي يقدمه خادم microapp عبارة عن صفحة HTML كاملة. لا يمكننا إدخال صفحة HTML الخاصة بالتطبيق المصغر ، كاملة مع علامات html ، و head ، و body ، في منتصف الصفحة الخاصة بتطبيق الماكرو ، هل يمكننا ذلك؟

نقوم بحل هذه المشكلة من خلال الاستفادة من ميزة علامة template التي يتم فيها تغليف محتوى التطبيق المصغر المسترجع من خادم microapp. اتضح أنه عندما تواجه المتصفحات الحديثة علامة template ، على الرغم من أنها لا "تنفذها" ، فإنها تقوم بتحليلها ، وبذلك تزيل المحتوى غير الصالح مثل علامات <html> و <head> و <body> ، مع الحفاظ على محتواها الداخلي. لذلك يتم الاحتفاظ <script> و <link> في <head> ، بالإضافة إلى محتوى <body> . هذا هو بالضبط ما نريده لأغراض إدراج محتوى microapp في صفحتنا.

بنية الواجهة الدقيقة: الشيطان يكمن في التفاصيل

سوف تتجذر الواجهات الأمامية الصغيرة في نظام webapp البيئي إذا (أ) تبين أنها نهج معماري أفضل ، و (ب) يمكننا معرفة كيفية تنفيذها بطرق تلبي المتطلبات العملية التي لا تعد ولا تحصى لشبكة الويب اليوم.

فيما يتعلق بالسؤال الأول ، لا أحد يدعي أن الواجهات المصغرة هي البنية الصحيحة لجميع حالات الاستخدام. على وجه الخصوص ، لن يكون هناك سبب وجيه لتطوير المجال الجديد من قبل فريق واحد لتبني واجهات صغيرة. سأترك السؤال عن أنواع التطبيقات في أي أنواع السياقات يمكن أن تستفيد أكثر من نمط الواجهة الأمامية الصغيرة للمعلقين الآخرين.

فيما يتعلق بالتنفيذ والجدوى ، فقد رأينا أن هناك تفاصيل متعددة يجب الاهتمام بها ، بما في ذلك العديد من التفاصيل التي لم يتم ذكرها في هذه المقالة - لا سيما المصادقة والأمان ، ونسخ الكود ، وتحسين محركات البحث. ومع ذلك ، آمل أن تحدد هذه المقالة نهج التنفيذ الأساسي للواجهات الأمامية الصغيرة التي يمكنها ، مع مزيد من التحسين ، مواجهة متطلبات العالم الحقيقي.

فهرس

  • نهايات أمامية دقيقة - النمط الزاوي - الجزء 1
  • نهايات أمامية دقيقة - النمط الزاوي - الجزء 2
  • تطوير تطبيق AngularJS باستخدام الواجهات الدقيقة
  • الواجهات الدقيقة
  • الخدمات المصغرة لواجهة المستخدم - عكس النمط المضاد (الواجهات الأمامية الصغيرة)
  • الخدمات المصغرة لواجهة المستخدم - مكافحة النمط؟
  • يتخذ بناء الصفحات باستخدام Micro-Frontends منهجًا شبيهًا بـ Yumcha للوكيل العكسي و SSIs ، وهو ما أوصي به بشدة.
  • موارد الواجهات الدقيقة
  • المنصة
  • أنا لا أفهم Micro-Frontends. هذه نظرة عامة جيدة لأنواع بنى الواجهة الصغيرة وحالات الاستخدام.
  • الواجهات الأمامية الصغيرة بدون خادم باستخدام Vue.js و AWS Lambda و Hypernova
  • Micro Frontends: نظرة عامة رائعة وشاملة.