عادةً ما يتم تقديم الميكرو-واجهات كاختراق تقني. في الممارسة العملية، هي غالباً ما تكون استراتيجية لتوسيع المنظمة.
تصبح جذابة عندما يتحول كود الواجهة الأمامية الواحد إلى عنق زجاجة في التسليم للعديد من الفرق. إذا كانت الفرق المستقلة لا تستطيع الشحن دون إعاقة بعضها البعض، فإن الضغط لإنشاء حدود نشر وملكية أقوى يصبح أمرًا حقيقيًا.
وهنا تدخل الفيدرالية الوحدوية والنهج المماثلة إلى المحادثة.
ما المشكلة التي تحلها فعليًا
تكون الميكرو-واجهات مفيدة عندما تحتاج إلى:
- وتيرة إصدار منفصلة
- حدود ملكية أقوى للفرق
- مجالات فشل محلية
- المزيد من الاستقلالية مما يسمح به بناء واجهة أمامية مشتركة
ليس هذا هو نفسه "التطبيق أحادي الصفحة لدينا فوضوي." التطبيق الفوضوي لا يصبح نظيفًا لمجرد أنك قسمته إلى حزم بعيدة.
لماذا ساعدت الفيدرالية الوحدوية
جعلت الفيدرالية الوحدوية لـ Webpack الميكرو-واجهات أكثر عملية لأنها سمحت للأعمال الفنية للواجهة الأمامية الموزعة بشكل منفصل بمشاركة الوحدات الزمنية وتحميلها ديناميكيًا:
new ModuleFederationPlugin({
name: "shell",
remotes: {
checkout: "checkout@https://cdn.example.com/remoteEntry.js",
},
shared: {
react: { singleton: true },
"react-dom": { singleton: true },
},
});
هذه تحسين حقيقي على iframes لعدة واجهات منتجات لأنها تحافظ على تجربة أكثر تماسكًا وتتجنب تكرار مجموعة التشغيل بأكملها بشكل غير ضروري.
المقايضات
لا تزال تدفع من أجل:
- تنسيق الاعتماد المشترك
- فشل تكامل زمن التشغيل
- إدارة عدم تطابق الإصدارات
- انحراف نظام التصميم
- تطوير محلي أكثر تعقيدًا
لذلك يجب أن تكون المعايير مرتفعة. إذا كانت المنظمة صغيرة بما يكفي بحيث لا يزال هناك واجهة أمامية مألوفة تعمل، فعادةً ما تكون هي الخيار الأفضل.
قواعد القرار الأفضل
استخدم الميكرو-واجهات عندما تحتاجها نموذج الفريق.
لا تعتمدها لأن الفرق الخلفية تستخدم بالفعل الخدمات الصغرى والشعور بالتناظر يبدو أنيقًا. إن تكامل زمن التشغيل الواجهة الأمامية يعتبر مجال مشكلة مختلف بتكاليف مختلفة.
قراءة إضافية