تحطيم بودكاست الحلقة 6 مع لوكا ميزاليرا: ما هي الواجهات الصغيرة؟

ننهي هذا العام ببودكاست Smashing آخر! هذه المرة ، سنتحدث عن الواجهات الدقيقة. ما هي الواجهة المصغرة؟ كيف تختلف عن نوع النهج الذي قد نتخذه في الوقت الحالي؟ دعنا نكتشف من رائد الواجهة المصغرة ، لوكا ميزاليرا.

وتظهر الملاحظات

تحديث اسبوعي

• "إضافة وظائف ديناميكية وغير متزامنة إلى مواقع JAMstack ،" جايسون لينجستورف
• "أدوات البيانات الكمية لمصممي UX ،" Adonis Raduca
• "إنشاء مهارات صوتية لمساعد Google و Amazon Alexa" ، Tris Tolliday
• "ما وراء Sprint 0: بديل لدمج الفرق" ، شمسي برين
• راشيل أندرو "مساعدة المتصفحات على التحسين باستخدام خاصية احتواء CSS"

الواجهات الدقيقة

• موقع الويب لوكا ميزاليرا
• لوكا على تويتر
• "Micro-Frontends ، مستقبل بنى الواجهة الأمامية" على المستوى المتوسط
• يمكن العثور على المزيد من كتابات Luca حول الواجهات الصغيرة على حسابه على موقع Medium
• كتاب لوكا "البنى التفاعلية للواجهة الأمامية"

نسخة طبق الأصل

درو ماكليلان: إنه خبير مطور في Google في تقنيات الويب ومدير مجتمع London JavaScript. مع أكثر من 15 عامًا من الخبرة ، يعمل حاليًا نائب الرئيس للهندسة المعمارية ، ويصمم منصة الفيديو الرياضية DAZN ، والتي تقدم محتوى رياضيًا عند الطلب لملايين المستخدمين الذين يشاهدون جميعًا على الهواء مباشرة. وهو مؤلف كتاب Front-End Reactive Architectures for Apress وهو أيضًا مراجع تقني لـ Apress و Packt Publishing و Pragmatic Bookshelf و O'Reilly ، فضلاً عن كونه متحدثًا عامًا متمرسًا في المؤتمرات التقنية في جميع أنحاء العالم. إنه إيطالي ، ولديه لحية وسيم ، ولديه معرفة عميقة بمنصة الويب. لكن هل تعلم أنه عبر مرة واحدة أمريكا الجنوبية على نعامة؟ أصدقائي المحطمون ، من فضلكم رحبوا بلوكا ميزاليرا. مرحبًا لوكا. كيف حالك؟

لوكا ميزاليرا: أنا محطمة.

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

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

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

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

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

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

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

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

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

لوكا: هذه ثلاثة من الخيارات التي لديك. وبصرف النظر عن التأليف ، فأنت بحاجة إلى التفكير في الطريقة التي تريد أن تسلك بها المسار. إذن كيف تتوجه من ، لا أعرف ، / تسجيل الدخول أو / تسجيل الدخول إلى جزء الكتالوج أو كائن تفصيلي محدد. أيضا هنا لديك مثل ثلاثة خيارات. يمكنك القيام بذلك على خادم التطبيق ، ويمكنك القيام بذلك على مستوى CDN باستخدام Lambda Edge أو أي عمال ويب آخرين في CloudFlare أو أي شيء آخر. أو يمكنك عمل موقع العميل. إذاً لديك منطق داخل غلاف التطبيق الخاص بك تقول ، حسنًا ، الآن بالنسبة لعنوان URL هذا المحدد ، تحتاج إلى تحميل عرض آخر أو واجهة مصغرة أخرى. والجزء الأخير هو كيفية تواصلك مع Micro-frontend.

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

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

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

لوكا: نعم ، أكثر من التكنولوجيا ، أرى أننا نختار التصميم المناسب للوظيفة المناسبة. فقط لإعطائك مثالاً ، كنت أتحدث ... هناك إطار عمل مشهور ، إطار جديد إلى حد ما لـ Micro-frontend ، يسمى إطار عمل Luigi ، والذي تم إصداره بواسطة SAP مفتوح المصدر. ما يفعلونه هو إنشاء بعض إطارات iframes حيث يتم تغليف الواجهة الأمامية الدقيقة الخاصة بهم بداخلها. لذلك إذا فكرت الآن في ذلك ، دعنا نقول ، باستخدام إطارات iframe في الوقت الحاضر ، فأنت على موقع ويب عام ربما يكون مُحسِّن محركات البحث أو ميزات أخرى إلزامية ، فقد يكون ذلك مشكلة.

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

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

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

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

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

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

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

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

درو: وهل يجب أن تستخدم كل هذه الفرق مثل إطار عمل JavaScript قياسي؟ هل يحتاجون جميعًا إلى الترميز في نفس الأشياء ، يجب أن يكونوا جميعًا إما React أو Angular أو لتمكين إمكانية التشغيل البيني بينهم أو هل يمكن للأشخاص استخدام أشياء مختلفة لواجهة Micro-front مختلفة؟

لوكا: أجل. لذلك في DAZN ، قررنا تقسيم واجهاتنا الصغيرة رأسيًا وكان ذلك قرارًا سمح لنا بالحرية في اختيار التكنولوجيا التي نحتاجها لكل واجهة Micro-front. بالنظر إلى أنه في كل مرة نقوم فيها بتحميل واجهة صغيرة واحدة في كل مرة ، وهذا يعني أنه على سبيل المثال ، تختلف الطريقة التي نحصل بها على صفحة مقصودة عن رحلة تسجيل الدخول / الاشتراك. حتى نتمكن من تحديث… نحن نستخدم React بشكل أساسي في الوقت الحالي. لكن إذا كنت أتذكر ، على سبيل المثال ، عندما كان React 16 إصدارًا تمكنا من إصداره في الإنتاج React 16 ، وكذلك إذا لم يكن في الإصدار الثابت لصفحة مقصودة فقط ومعرفة ما إذا كان يعمل دون التأثير على كل فرق أخرى.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درو: يبدو أنه حل جذاب للغاية لبعض المشاكل أنا متأكد من أن الكثير من الناس يواجهونها. إذا كنت ، كمطور ، أرغب في البدء في التحقيق أكثر حول Micro-frontend ، فأين سيكون مكانًا جيدًا للبدء؟

لوكا: نعم ، أقضي حاليًا الكثير من وقت فراغي في محاولة الدفاع عن هذه الهندسة المعمارية ، لأنني أعتقد أن هناك الكثير من المفاهيم الخاطئة. على حساب ميديوم الخاص بي. لقد كتبت العديد من المقالات المتوفرة هناك أيضًا. قام بتسجيل الكثير من مقاطع الفيديو في المؤتمرات التي يمكنك أن تجدها على موقع يوتيوب دون أي مشكلة. والشيء الآخر الذي أقترحه إذا كنت تبحث عن بعض أمثلة التعليمات البرمجية في بعض الأطر ، فإن النموذج الذي أوصي بالبدء به هو SPA واحد ، ويرجع ذلك أساسًا إلى أنه يحتوي على نهج التقطيع العمودي ، ومن السهل التقاطه و يمكنك البدء في فهم فوائد هذه البنية. ثم هناك العديد من الآخرين المتاحين. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.