اتحاد الوحدات (Module Federation): الدليل الشامل لمشاركة الوحدات البرمجية وقت التشغيل في الواجهات الأمامية المصغرة

في المشهد المتطور باستمرار لتطوير الويب، شهدنا تحولًا معماريًا كبيرًا. رحلتنا من البنى المتجانسة (monolithic) إلى الخدمات المصغرة للخلفية (backend microservices)، سعيًا وراء قابلية التوسع واستقلالية الفرق. الآن، نفس هذه الثورة تغير الواجهة الأمامية. لقد حان عصر الواجهات الأمامية المصغرة (micro-frontends)، وفي قلبه تكمن تقنية قوية تجعل كل هذا عمليًا: اتحاد الوحدات (Module Federation).

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

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

مراجعة سريعة: ما هي الواجهات الأمامية المصغرة؟

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

تقوم بنية الواجهات الأمامية المصغرة بتقسيم هذا الهيكل المتجانس وفقًا لمجالات العمل. قد يكون لديك:

• فريق البحث الذي يمتلك شريط البحث وصفحة النتائج.
• فريق المنتج الذي يمتلك تفاصيل المنتج والتوصيات.
• فريق الدفع الذي يمتلك عربة التسوق وعملية الدفع.

يمكن لكل فريق بناء واختبار ونشر الجزء الخاص به من التطبيق بشكل مستقل. يؤدي هذا إلى العديد من الفوائد الرئيسية:

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

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

الطرق القديمة لمشاركة الكود (ولماذا هي قاصرة)

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

حزم NPM

النهج الأكثر شيوعًا هو نشر المكونات أو الأدوات المساعدة المشتركة كحزمة NPM ذات إصدار. مكتبة المكونات المشتركة هي مثال كلاسيكي.

• المشكلة: هذه تبعية وقت البناء (build-time). إذا قام الفريق أ بتحديث مكون `Button` المشترك في `my-ui-library` من الإصدار 1.1 إلى 1.2، فلن يحصل الفريق ب والفريق ج على هذا التحديث حتى يقوموا بتحديث ملف `package.json` يدويًا، وتشغيل `npm install`، وإعادة نشر واجهتهم الأمامية المصغرة بالكامل. هذا يخلق اقترانًا وثيقًا ويقوض الغرض من عمليات النشر المستقلة. كما يؤدي أيضًا إلى تحميل إصدارات متعددة من نفس المكون في المتصفح، مما يضخم الحزمة النهائية.

المستودعات الأحادية (Monorepos) مع مساحات العمل المشتركة

المستودعات الأحادية (باستخدام أدوات مثل Lerna أو مساحات عمل Yarn/NPM) تحتفظ بجميع الواجهات الأمامية المصغرة في مستودع واحد. هذا يبسط إدارة الحزم المشتركة.

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

الاسكربتات الخارجية عبر وسوم `