مقدمة

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

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

كيف تبدو عمارة الواجهة الأمامية المصغرة فعليًا

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

تتباين أساليب التكامل بشكل كبير في مفاضلاتها. يقدم التكامل وقت البناء، حيث تُصرَّف الواجهات الأمامية المصغرة معًا في حزمة واحدة قبل النشر، أداءً قويًا لعدم وجود عبء وقت تشغيل، لكنه يُعيد إدخال درجة ذات معنى من عنق زجاجة التنسيق. يُحمّل التكامل وقت التشغيل في المتصفح، المُنفَّذ شائعًا عبر Module Federation الخاص بـWebpack، حزم JavaScript المنشورة بشكل مستقل من فرق منفصلة ديناميكيًا وقت التشغيل، محافظًا على قابلية نشر مستقلة حقيقية بتكلفة تعقيد إضافي من جانب العميل وخطر حقيقي لتكرار الحزم إذا لم تكن الفرق منضبطة بشأن مشاركة تبعيات شائعة مثل إطار واجهة مستخدم. يقدم التكامل من جانب الخادم، المُسمى أحيانًا التركيب من جانب الخادم، أرضية وسطى تجمع الصفحة النهائية من شظايا منشورة بشكل مستقل على مستوى الخادم أو CDN قبل وصولها للمتصفح.

حجة الواجهات الأمامية المصغرة

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

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

التكاليف الحقيقية: الأداء والاتساق والتعقيد

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

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

دراسة حالة: نموذج فرق Spotify وملكية الواجهة الأمامية

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

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

الحالة المشتركة والتواصل بين الفرق

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

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

متى تكون الواجهات الأمامية المصغرة الخيار الخاطئ

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

الخاتمة

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