Microfronts: ما الذي نتحدث عنه؟

كل هذه السنوات ، أنت ، مطور الواجهة الأمامية ، كتبت متراصة ، على الرغم من أنك تفهم أن هذه العادة سيئة. لقد قسمت الكود إلى مكونات ، واستخدمت أو import وحُددت حزم npm في package.json أو قمت بإنشاء مستودعات git في مشروعك ، لكنك كتبت متراصة على أي حال.
حان الوقت لتغيير الموقف.

لماذا يمكن اعتبار الكود الخاص بك متراصة؟

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

ما هي الخدمات الصغيرة؟

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

يطور المطورون الذين يتفاعلون مع خدمات microservices أحجام مختلفة. أكبرها يجتمع مع إستراتيجية فريق أمازون المكون من بيتزا اثنين - لا يزيد عن 10-12 شخص. القطب العكسي - فرق من 5-6 أشخاص ، حيث يدعم كل منهم خدمة واحدة.

فيما يلي رسم تخطيطي يوضح الفرق بين الخدمات المتجانسة والخدمات الصغيرة:



يمكن أن يتضح من الرسم التوضيحي أن كل خدمة في نظام microservice هي تطبيق منفصل ، باستثناء واجهة المستخدم - تظل كل واحدة! عندما يتم دعم جميع الخدمات بواسطة فريق واحد ، يكون المخاطرة كبيرة أنه مع نمو الشركة ، لن يتمكن فريق الواجهة الأمامية من مواكبة واجهة المستخدم. هذا هو ضعف هذه البنية.



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

حل للمشكلة: microfronts

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

مبدأ microfronts: عرض موقع ويب أو تطبيق ويب كمجموعة من الوظائف التي تكون الفرق المستقلة مسؤولة عنها. لكل فريق مهمته الخاصة ، مجال عمله الذي يتخصص فيه. الفريق متعدد الوظائف ويتطور
الدورة بأكملها - من قاعدة البيانات إلى واجهة المستخدم ( micro-fontend.org ).

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

الهيكل العام وبعض المصطلحات الأخرى

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



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

المشاكل التي يتعين حلها

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

المشكلة رقم 1: تحقيق سلوك ثابت ومتسق من واجهة المستخدم عندما يكون لدينا العديد من التطبيقات الصغيرة المستقلة تمامًا

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

خيار آخر هو إنشاء متغيرات CSS شائعة على مستوى الجذر. تتمثل ميزة هذا الحل في حصولنا على سمة مخصصة عامة لجميع التطبيقات.

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

المشكلة رقم 2: تأكد من عدم قيام فريق ما بإعادة كتابة CSS لفريق آخر

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

ثانياً ، يمكنك جعل كل تطبيق مصغر يصبح مكون ويب مخصصًا . ميزة هذا النهج هو أن المتصفح يتعامل مع التقييد. ومع ذلك ، كل شيء له ثمن: مع Shadow DOM ، يكاد يكون من المستحيل تقديمه على جانب الخادم. بالإضافة إلى ذلك ، لا تدعم المستعرضات العناصر المخصصة بنسبة 100٪ - خاصة إذا كنت بحاجة إلى دعم IE.

المشكلة رقم 3: جعل المعلومات العالمية مشتركة بين التطبيقات الصغيرة المختلفة

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

قد يساعد تطبيق pub-sub أو T39 أيضًا. إذا كنت بحاجة إلى معالج حالة عالمي أكثر دقة ، فيمكنك تنفيذ برنامج Redux عام صغير - مما يوفر بنية أكثر استجابة.

المشكلة رقم 4: إذا كانت جميع التطبيقات الصغيرة مستقلة ، فكيف يتم إجراء التوجيه من جانب العميل؟

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

تتمثل طريقة عملي في إنشاء جهاز توجيه مشترك للعميل ، يكون مسؤولاً فقط عن طرق المستوى الأعلى ، والباقي تحت رحمة التطبيقات الصغيرة المقابلة. لنفترض أن لدينا تعريف الطريق /content/:id. سيحل جهاز التوجيه المشترك الجزء c /content ، وسيتم تمرير المسار الذي تم حله إلى ContentMicroApp. ContentMicroApp هو خادم قائم بذاته سيتم استدعاؤه فقط بـ /:id .

المشكلة رقم 5: هل نحن بحاجة حقًا إلى SSR (العرض من جانب الخادم) ، هل من الممكن عند استخدام microfronts؟

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

المشكلة 6: "التكامل مع البيئة الحالية ضروري مثل الهواء! كيف اصنعها؟

للتكامل مع الأنظمة الحالية ، أريد أن أصف رؤيتي ، والتي أسميها " التنفيذ التدريجي ".

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

والخطوة التالية هي التنفيذ التدريجي. سنأخذ قطعة صغيرة من LegacyMicroApp ، مع إزالة التنقل الرئيسي ، واستبداله بالتبعية. هذه التبعية هي تطبيق صغير يتم تنفيذه باستخدام تقنية رائعة جديدة ، NavigationMicroApp.

الآن سوف LegacyMicroApp اعتراض جميع الطرق من خلال التبعية NavigationMicroApp ومعالجتها داخليا.

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

لذلك سوف نستمر في عض قطعة من LegacyMicroApp حتى لا يتبقى منها شيء.

المشكلة رقم 7: تنظيم جانب العميل بحيث لا تضطر إلى إعادة تحميل الصفحة في كل مرة

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

يمكن دمج المشكلات المذكورة أعلاه في الموضوعات التالية:

جانب العميل

• تزامن
• التوجيه
• العزلة الدقيقة
• تفاعل التطبيق
• الوحدة UI تطبيقات الصغرى

جانب الخادم

• تقديم الخادم
• التوجيه
• إدارة التبعية

العمارة مرنة وقوية ولكن بسيطة

من أجل هذا ، كان يستحق تحمل بداية المقال! العناصر والمتطلبات الرئيسية للهيكل microfrontend بدأت أخيرًا في الظهور ؛)

مسترشداً بالمتطلبات والاهتمامات ، بدأت في تطوير حل يسمى microfe . * تحسبا لردود الفعل *
هنا سوف أوجز بنية المشروع ، مع وصف موجز لمكوناته الرئيسية.

أسهل طريقة للبدء هي من جانب العميل ، الذي يحتوي على ثلاثة هياكل رئيسية منفصلة: AppsManager ، Loader ، Router ، بالإضافة إلى واحدة إضافية ، MicroAppStore .



AppsManager
AppsManager هو جوهر تزامن التطبيق الصغير من جانب العميل. الهدف الرئيسي من AppsManager هو إنشاء شجرة تبعية. بمجرد حل جميع التبعيات ، يقوم AppsManager بتشغيل التطبيق المصغر.

محمل
جزء مهم آخر من تزامن جانب العميل هو Loader. إنه مسؤول عن تنزيل التطبيقات من جانب العميل.

راوتر
لأداء التوجيه من جانب العميل ، قمت بتنفيذ جهاز التوجيه في الميكروف. على عكس أجهزة التوجيه التقليدية من جانب العميل ، فإن جهاز التوجيه microfe لديه وظائف محدودة. إنه لا يعالج الصفحات ، لكن التطبيقات الصغيرة. دعنا نقول لدينا URL /content/detail/13 و ContentMicroApp. في هذه الحالة ، سيقوم جهاز التوجيه المصغر بمعالجة عنوان URL إلى /content/* والاتصال /content/* ContentMicroApp /detail/13 .

MicroAppStore
لحل تفاعل العميل بين التطبيقات الصغيرة ، قمت بتنفيذ MicroAppStore في microfe. لديها نفس وظيفة مكتبة Redux ، ولكن مع تحذير واحد: إنها أكثر مرونة فيما يتعلق بتعديل البيانات غير المتزامنة وإعلان الاختزال.

***

ربما يكون جانب الخادم أكثر تعقيدًا بعض الشيء في التنفيذ ، ولكن له بنية أبسط. وهو يتألف من جزأين رئيسيين - StitchingServer و MicroAppServer.

MicroAppServer

يمكن التعبير عن أصغر وظيفة MicroAppServer على النحو التالي: الحرف الأول والعرض.
عند بدء تشغيل MicroAppServer ، فإن أول شيء يجب فعله هو استدعاء SticthingServer وتسجيل نقطة نهاية مع التطبيق الصغير المعلن عنه. إنه يحدد التبعيات وأنواع وعناوين URL الخاصة بمخطط MicroAppServer ، وأعتقد أن التحدث عن خدمة غير ضروري - لا يوجد شيء مثير للاهتمام هنا.

خادم خياطة

يتيح لك StitchingServer تسجيل نقطة نهاية مع MicroAppServers. عندما تسجل MicroAppServer مع StichingServer ، تسجل StichingServer إعلان MicroAppServer.

في وقت لاحق ، يستخدم StitchingServer الإعلان لحل MicroAppServices من عنوان URL المطلوب.

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

ثم تدخل المهمة الرئيسية لـ StitchingServer إلى المشهد: تجميع جميع الأجزاء المستلمة وإرجاع صفحة HTML بأكملها.

بضع كلمات عن التطبيقات الأخرى

حتى قبل ظهور مصطلح microfrontend في عام 2016 ، حاولت العديد من الشركات الكبيرة حل مشكلات مماثلة - على سبيل المثال ، Facebook مع BigPipe .
الآن الفكرة تكتسب زخما. تهتم الشركات من جميع الأحجام بهذا الموضوع ، وتستثمر الوقت والمال فيه. على سبيل المثال ، قدمت Zalando شفرة المصدر المفتوح لحل مشروع الفسيفساء . أستطيع أن أقول إن microfe و Project Mosaic يتبعان أساليب مماثلة ، لكن مع بعض الاختلافات الأساسية. إذا لجأ microfe إلى التوجيه اللامركزي بالكامل لجعل كل تطبيق مصغر أكثر استقلالية ، فإن Project Mosaic يفضل التوجيه المركزي وتعريف النمط لكل مسار. بالمناسبة ، يجعل Project Mosaic من السهل إجراء اختبار AB وتوليد القوالب الديناميكية أثناء التنقل.

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

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

الخلاصة (والروابط)

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

خادم التطبيق الصغير fe التسجيل
البنية التحتية الجزئية الأمامية