الواجهات الدقيقة. التعلم من الأخطاء

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

الواجهات الدقيقة في إطار iframe

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



كحجة ، بالمناسبة ، تم تقديم منتج Office 360 ​​من Microsoft ، وكان يستخدم سابقًا <iframe /> `للقوائم العلوية والجانبية. الآن لا توجد إطارات iframe.

الأسباب والمتطلبات الأساسية للواجهات الدقيقة

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



جميع التطبيقات المتاحة هي React SPA. ليس لديهم أي شيء مشترك باستثناء Material UI و React Router v4 ومجموعة embryo UI-kit كوحدات npm.



سيتم استخدام بعض التطبيقات وتسليمها في إصدار مستقل وكجزء من تطبيق آخر.



تم تقسيم الواجهات الدقيقة إلى كتل وظيفية كبيرة:

1. رأس التطبيق. التوجيه بين التطبيقات
2. تطبيق لوحة القيادة. مع المقاييس والحاجيات. يجب أن تكون كل أداة لوحة تحكم جزءًا من التطبيق المقابل (متصل عبر iframe).
3. التطبيقات نفسها. بعضها يشمل أجزاء من بعضها البعض (لكن بدون تعصب وتكرار)

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

المشكلة رقم 0. الفصل غير الصحيح للواجهات الدقيقة

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







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



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



نتيجة لذلك ، فشل توفير الوقت عند إعادة استخدام التطبيقات. كما ظل ازدواجية الوظائف عند مستوى عالٍ. يمكن أن يؤدي استخدام microfront-end بدون إطارات iframe أو مكونات ذات منطق أكثر تعقيدًا من مجموعة UI الممتدة إلى حل مشكلة ازدواجية الوظائف.

المشكلة رقم 1. عدم تنسيق العملية

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



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



https://domain.zone/dashboard

https://domain.zone/header

https://domain.zone/app1

https://domain.zone/app2

https://domain.zone/api1

https://domain.zone/api2







هذا هو المكان الذي تأتي فيه حزمة "http-proxy-middleware" للإنقاذ ، والتي يمكن تهيئتها بالاشتراك مع CRA. اتضح أن نصف مطوري الواجهة الأمامية فقط كانوا قادرين على إعداد مثل هذا الإعداد. بالطبع لا يمكن أن يلوم أحد هنا ولكن مثل هذه المشكلة ظهرت ويجب حلها تنظيمياً.



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

المشكلة رقم 2. عدم وجود واجهة برمجة تطبيقات داخلية

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



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



من الضروري أيضًا تطوير آلية للاتصال بين التطبيقات. هنا تأتي `postMessage API` للإنقاذ ، أو الوصول المباشر إلى آخر ، مدمج في كل تطبيق React تقريبًا - Redux. ما ليس ناقل الرسائل؟ ولكن أكثر عن ذلك لاحقا.

المشكلة رقم 3. Iframe ليس مرنًا بدرجة كافية

لا حرج في استخدام العلامة `<iframe />`. إنها أداة قوية مع ناقل رسائل مدمج (postMessage API) وتخصيص أمني شامل.



ومع ذلك ، في حالة microfront ، فإن "<iframe />` يفرض الكثير من القيود. أحدها هو عدم القدرة على إعادة استخدام تطبيق واحد في عدة أجزاء من الصفحة.

إعادة استخدام التطبيقات

في حالة تشبيه المتجر عبر الإنترنت ، ستنشئ 10 أزرار شراء 10 `` <iframe /> `، أي 10 تطبيقات تعمل في React. لا توجد ذاكرة كافية لهذا. هذا هو أحد أسباب عدم إمكانية تقسيم التطبيق إلى فرق حسب الميزات.

عنوان URL غير مناسب لإدارة الحالة

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



فيما يلي مثال على كيفية عمل تطبيق أرجواني من KDPV بعنوان URL مختلف كتطبيق مستقل:







ومع ذلك ، فقد تبين أن استخدام واجهة URL iframe لتبديل حالة الواجهة المصغرة في حالتنا أمر مستحيل: تبدأ الواجهة المصغرة في التحميل من نقطة الصفر بسبب التكامل غير الكامل لواجهة برمجة التطبيقات مع "pushState" `وتتفاعل راوتر - الحصول على كامل الصفحة التحديث.

خارج معالجات النقر فوق ʻiframe`

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



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

مشكلة المكافأة: استخدام ملفات تعريف الارتباط غير المناسب

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



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

نتيجةً لذلك ، تجاوز حجم ملف تعريف الارتباط 8 كيلوبايت ، وهي القيمة الافتراضية لـ nodejs / nginx (أو 2 كيلوبايت لحجم سجل ملف تعريف ارتباط واحد في Google Chrome) ، مما أدى إلى تكوين خادم أكثر تعقيدًا (بدون إخراج CRA ، لا يمكنك البدء بهذا الإعداد) ، و أيضًا لتقسيم مجموعة البيانات الكبيرة المشفرة هذه إلى سلاسل ملفات تعريف ارتباط أصغر.



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

خاتمة. كيف إذن العيش مع واجهات صغيرة؟

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

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