جدول المحتويات[يخفي][يعرض]
اكتسبت فكرة الخدمات المصغرة الكثير من الاهتمام مؤخرًا ، وتستخدمها العديد من الشركات للتخلص من الخلفيات الخلفية الكبيرة والمتجانسة.
لا يزال اتباع نفس المسار مع الواجهة الأمامية يمثل تحديًا للعديد من الشركات ، حتى لو كانت هذه الطريقة الموزعة لإنشاء جانب الخادم لتطبيقات الويب أكثر أو أقل موثوقية من حيث البحث والتنفيذ.
نظرًا لاعتمادها الوثيق ، فإن الوحدة المتراصة من جانب العميل تجعل من الصعب عادةً دمج ميزات جديدة ، واعتماد تقنيات جديدة ، وتوسيع نطاق المكونات الفردية.
دفعت هذه التحديات وغيرها مطوري الواجهة الأمامية للتحقيق في استخدام الخدمات المصغرة.
نتيجة لذلك ، تم تطوير إستراتيجية معمارية جديدة تمامًا تُعرف باسم الواجهة الأمامية المصغرة لإنشاء طبقة الواجهة الأمامية لمواقع الويب والتطبيقات المستندة إلى الويب.
تم استخدام المصطلح لأول مرة في عام 2016 ، ومنذ ذلك الحين ، جذب الكثير من الاهتمام لسبب وجيه.
ستعطي هذه المقالة فهمًا عامًا لماهية الواجهات المصغرة والقضايا التي تتناولها. إنه يعمل ، بالإضافة إلى الإيجابيات والسلبيات.
مقدمة في العمارة الأمامية الدقيقة
طريقة معاصرة لتطوير الواجهة الأمامية تسمى هندسة الواجهة الأمامية الدقيقة تقسم أ تطبيق ويب إلى أجزاء صغيرة مستقلة.
بالنسبة للمستخدم النهائي ، تبدو هذه الأجزاء وكأنها وحدة واحدة حتى لو تم إنشاؤها بشكل مستقل ثم تم تجميعها معًا.
مع الاختلاف في أن الواجهات الأمامية الصغيرة تتعلق بجانب العميل ، وليس جانب الخادم ، للحلول عبر الإنترنت ، فإن الأساس المنطقي الكامن وراءها مطابق لتلك الخاصة بالخدمات المصغرة.
يعتبر صنع منتجات متطورة قائمة على الويب أكثر منطقية عند استخدام نهج الواجهة الأمامية المصغرة.
تمكّن الواجهات الأمامية الصغيرة ، على عكس الواجهة الأمامية المتراصة الأكثر تقليدية ، العديد من الفرق من التعاون بشكل منفصل في مشاريع برمجية مختلفة.
يمكن للمبرمجين إنشاء تطبيقات الويب بسرعة أكبر مع قابلية أكبر للتوسع وقابلية الصيانة باستخدام هذا التصميم المعماري.
بكل بساطة ، كل واجهة أمامية صغيرة هي مجرد جزء من التعليمات البرمجية لمكون مميز لصفحة الويب.
يتم التحكم في هذه الميزات من قبل فرق منفصلة ، كل منها متخصص في صناعة أو هدف معين.
Monolithic مقابل Microservices مقابل Micro Frontend architecture
فكر في الانتقال. هل سيكون من الأسهل بالنسبة لك تنظيم كل شيء في عدد من الصناديق الصغيرة المصنّفة بخبرة ونقل كل منها على حدة أو تجميع الموظفين بالكامل في صندوق ضخم واحد ونقله إلى موقع جديد؟
الحل الواضح موجود.
يقارن هذا القياس بنيتي تطبيقات الويب المتميزة ، وهما monoliths والخدمات المصغرة (المعروفة أيضًا باسم الواجهات الأمامية الصغيرة).
العمارة المتجانسة
قد تتمكن من تذكر "الأيام الخوالي" عندما تم إنشاء تطبيق كامل ككيان واحد متماسك. تسمى هذه الطريقة متراصة ، وهو مصطلح قديم للكتلة الحجرية الكبيرة.
هذا يبدو منطقيا.
الأنظمة المتجانسة لها عناصر مترابطة. لذلك ، إذا كنت ترغب في تعديل شيء ما أو إضافة ميزة جديدة ، فمن المحتمل أن ينكسر النظام بأكمله.
على الرغم من أنها قديمة ، إلا أنها لا تزال موجودة في بعض الأحيان. نعم ، نحن على دراية بتعبيرك الحالي.
أصبح التقسيم المفاهيمي لقاعدة التعليمات البرمجية إلى مكونين مختلفين - الواجهة الأمامية (جانب العميل) والخلفية (جانب الخادم) - أمرًا لا مفر منه مع تطور التقنيات الجديدة وتصبح منتجات البرامج أكثر تعقيدًا.
أكثر طرق التشغيل شيوعًا هي الآن فصل الاهتمامات بين طبقة العرض التي يتفاعل معها المستخدم النهائي وكل ما يحدث في الخلفية.
تحتاج إلى فريقين لهندسة البرمجيات ، مع فريق الواجهة الأمامية لبناء المكونات المرئية وفريق النهاية الخلفية لبناء خدمات الويب ، ومنطق الأعمال ، والوصول إلى البيانات ، والتكامل ، وما إلى ذلك.
ومع ذلك ، على الرغم من هذا الفصل ، لا تزال هذه الاستراتيجية متجانسة بطبيعتها.
التغيير الرئيسي هو أن لدينا الآن كتلتين كبيرتين من التعليمات البرمجية - الواجهة الأمامية والخلفية - بدلاً من تطبيق واحد ضخم. لا يجب أن تكون الأبنية المتجانسة رهيبة ؛ لديهم بعض الفوائد ، بما في ذلك
- تطوير بسيط وسريع للتطبيقات الصغيرة باستخدام مصدر شفرة واحد وتصميم بسيط للغاية ؛
- يعتبر الاختبار وتصحيح الأخطاء واضحين للغاية لأن جميع التعليمات البرمجية موجودة في مكان واحد ، مما يسهل على الفريق تتبع تدفق الطلب وتحديد الأخطاء ؛
- في وقت مبكر من تطوير التطبيق ، تكون النفقات أرخص حيث لا يتم تكبد تكاليف البنية التحتية ولا تكاليف التطوير حتى يتم إضافة ميزات جديدة.
تنعكس عيوب هذه الاستراتيجية في
- مرونة النشر المقيدة - يجب أن تنتظر الفرق إذا كان هناك عدد قليل منهم فقط يعملون في المشروع ويكون النشر الجديد مطلوبًا في كل مرة تقوم فيها بتحديث الرمز ؛
- يعد اعتماد تقنيات جديدة أمرًا صعبًا لأن القيام بذلك يتطلب إعادة كتابة جزء كبير ، إن لم يكن المشروع بأكمله.
- عندما يزداد عدد المطورين ، يصبح نظام الكود مرتبطًا بشكل وثيق ومعقدًا ويصعب إدارته وفهمه.
- القضايا التنظيمية - يجب على كل عضو في الفريق استخدام نفس إصدار المكتبات والإبلاغ عن أي تغييرات إذا كانت العديد من الفرق تعمل في مشروع موحد.
- مخاوف من قابلية التوسع - نظرًا لأن مكونات المشروع مترابطة ، فإن توسيع نطاقها بشكل منفصل يمثل صعوبات تؤدي إلى تعطل كبير ونفقات أعلى.
- قد يكون من الصعب على أعضاء الفريق الجدد فهم منطق المشروع المعقد ، خاصةً إذا لم يعد المهندسون الذين عملوا عليه في الأصل يعملون.
عالج تطوير الخدمات المصغرة وأقاربها ، والواجهات الصغيرة ، المشكلات الأساسية للأنظمة المتجانسة.
هندسة الخدمات المصغرة
تسمح الطريقة المعمارية المعروفة باسم الخدمات المصغرة بإنشاء العديد من المكونات أو الخدمات الأصغر المرتبطة بشكل غير وثيق والتي يمكن نشرها بشكل مستقل والتي تشكل الواجهة الخلفية للتطبيق.
تحتوي كل خدمة على قاعدة بيانات خاصة بها وخطوط أنابيب CI / CD وإجراءات DevOps وعمليات تشغيلها.
يمكنك أن ترى أن فريق الخلفية المتجانسة مقسم إلى فرق منفصلة من خلال النظر إلى الصورة أعلاه.
يركز كل منها بشكل فردي على جانب مختلف من التطبيق (مثل خدمة المنتج وخدمة البحث وخدمة الدفع).
يحدث الاتصال بين الخدمات من خلال البروتوكولات المعمول بها والمعروفة باسم واجهات برمجة التطبيقات ، مثل بروتوكول REST API خفيف الوزن الذي يستخدم أنماط الطلب والرد المتزامنة.
خيار آخر هو استخدام الاتصال غير المتزامن باستخدام برنامج مثل كافكا ، والذي يقدم هياكل وأحداث اتصال للنشر / الاشتراك.
تتكامل الخدمات المصغرة مع الواجهة الأمامية عبر واجهة خلفية لخدمة الواجهة الأمامية (BFF) أو بوابة API عبر الشبكة. يوفر BFF واجهة برمجة تطبيقات مخصصة لكل عميل ، بينما توفر API Gateways نقطة وصول واحدة لمجموعة من الخدمات المصغرة.
ولكن حتى مع مكونات الواجهة الخلفية المستقلة وجميع المزايا التي توفرها ، لا تزال الواجهة الأمامية متراصة.
لذلك ، هذا هو المكان الذي تكون فيه الواجهات الصغيرة مفيدة.
بنية الواجهات الصغيرة
على غرار الخدمات المصغرة ، حيث تتم إدارة المكونات المرتبطة بشكل فضفاض من قبل عدة فرق ، تطبق بنية الواجهة الأمامية المصغرة المفهوم على المتصفح.
تتبع واجهات مستخدم تطبيقات الويب هذه الهيكل ، الذي يتكون من مكونات مستقلة إلى حد ما.
يتم إنشاء الفرق أيضًا بناءً على احتياجات العميل أو حالات الاستخدام بدلاً من الخبرة أو التكنولوجيا الخاصة.
وبالتالي ، تشارك الفرق في الخدمات المصغرة ومشاريع الواجهة الأمامية الصغيرة.
- مقطع عموديًا - نظرًا لوجود مطوري الواجهة الأمامية وخبراء البيانات ومهندسي الواجهة الخلفية ومهندسي ضمان الجودة وما إلى ذلك ، يعملون في نفس المشروع أيضًا ، فإنهم ينشئون ميزاتهم من واجهة المستخدم لقواعد البيانات و
- متعدد الوظائف - يساهم كل عضو في الفريق بخبرته في المجموعة.
يمكن للفرق أيضًا تحديد مجموعة التقنيات التي تناسب خط أعمالهم الخاص على أفضل وجه.
يمكن لفريق واحد استخدام React لبرمجة جزئها. يقوم فريق آخر بإنشاء إصدار Angular جديد. Vue.js هو أحد الأمثلة.
تُستخدم الواجهات الأمامية الصغيرة جنبًا إلى جنب مع الخدمات المصغرة ذات الصلة لمعالجة المشكلات التي تواجهها فرق التطوير عادةً مع الوحدات المتراصة. تقدم الاستراتيجية المزايا التالية.
- حرية التكنولوجيا: يمكن لمهندسي الواجهة الأمامية اختيار أطر عمل جافا سكريبت بديلة وبيئات وقت التشغيل ومجموعات التكنولوجيا بأكملها وفقًا لاحتياجات الشركة. علاوة على العمارة القديمة ، يمكن تطبيق إطار عمل جديد.
- يمكن الحصول على درجة أكبر من المرونة نظرًا لأن كل واجهة أمامية صغيرة قائمة بذاتها ويمكن تطويرها واختبارها ونشرها وترقيتها بشكل منفصل. نتيجة لذلك ، إذا كان أحد الفريقين يعمل على ميزة وقام بإصلاح الأخطاء ، وكان على فريق آخر إضافة ميزته الخاصة ، فلن يحتاجوا إلى انتظار الفريق الأول لإكمال مهمته.
- الفرق والأنظمة المستقلة: يمكن لكل فريق منتج ، وبالتالي كل ميزة ، العمل مع القليل من الاعتماد على الآخرين ، مما يمكّنه من مواصلة العمل حتى عندما تكون المكونات القريبة غير متوفرة.
- قواعد أكواد متعددة وأصغر: سيكون لكل واحدة من الواجهات الأمامية الصغرى قاعدة شفرات خاصة بها ، وأكثر قابلية للإدارة ، وأصغر حجمًا. سوف يركز عدد أقل من الأشخاص على مكون محدد لواجهة المستخدم ، ويبسطون مراجعات الكود ، ويحسنون التنظيم العام.
- توسيع نطاق التطبيق البسيط: ميزة أخرى للواجهات الأمامية الصغيرة هي القدرة على توسيع نطاق كل ميزة على حدة. على عكس monoliths ، حيث يجب تغيير حجم البرنامج بأكمله في كل مرة يتم فيها إضافة ميزة جديدة ، وهذا يجعل العملية بأكملها أكثر كفاءة من حيث الوقت والمال.
كيف تعمل الواجهة الأمامية المصغرة؟
كما ذكرنا سابقًا ، يتم تنظيم الفرق رأسياً داخل بنية الواجهة الأمامية المصغرة ، مما يعني أنها مفصولة بمعرفة المجال أو الغرض وتكون مسؤولة من البداية إلى النهاية عن منتج معين.
يمكن أن تحتوي على واحدة أو اثنتين من الخدمات المصغرة الخلفية بالإضافة إلى واجهة أمامية صغيرة. بمزيد من التفصيل ، دعنا نفحص خصائص هذا العنصر المرئي ، والتفاعلات مع مكونات واجهة المستخدم الأخرى ، ودمجها في الصفحة الرئيسية.
يمكن أن تكون الواجهة الأمامية الصغيرة
- صفحة كاملة (على سبيل المثال ، صفحة تفاصيل المنتج) أو
- أقسام الصفحة التي يمكن استخدامها بواسطة فرق أخرى ، مثل الرؤوس والتذييلات وأشرطة البحث.
يمكنك تقسيم موقع ويب كبير إلى عدة أنواع من الصفحات وإعطاء كل نوع لموظف معين للعمل عليه.
ومع ذلك ، غالبًا ما تحدث العديد من المكونات في العديد من الصفحات ، مثل الرؤوس والتذييلات وكتل الاقتراحات وما إلى ذلك. يمكن تضمين كتلة الاقتراح ، على سبيل المثال ، في الصفحة الرئيسية أو صفحة تفاصيل المنتج أو حتى صفحة الخروج.
في الأساس ، يمكن للفرق إنشاء قطع يمكن للفرق الأخرى استخدامها على صفحاتهم.
ومع ذلك ، يمكن نشر الواجهات الصغيرة بشكل منفصل كمشاريع مختلفة على عكس المكونات القابلة لإعادة الاستخدام.
كل هذا يبدو رائعًا ، ولكن لإنشاء واجهة موحدة ، يجب دمج الصفحات والأجزاء بطريقة ما.
يتطلب ذلك تكامل الواجهة الأمامية ، والذي يمكن تحقيقه عبر مجموعة متنوعة من الاستراتيجيات ، بما في ذلك التوجيه والتكوين والاتصال (انظر الرسم أعلاه).
التوجيه
عندما تكون الخدمة من صفحة يتحكم فيها فريق واحد مطلوبة للوصول إلى صفحة يملكها فريق آخر ، يكون التوجيه مفيدًا للتكامل على مستوى الصفحة.
يتم التعامل مع كل واجهة أمامية صغيرة كتطبيق من صفحة واحدة. يمكن استخدام روابط HTML البسيطة لتوفير التوجيه.
يمكن للمستخدم إجبار المتصفح على تنزيل الترميز الهدف من الخادم واستبدال الصفحة الحالية بالصفحة الجديدة بالنقر فوق الارتباطات التشعبية.
غلاف التطبيق هو الحد الأدنى من HTML و CSS و JavaScript الذي يدعم واجهة المستخدم. حتى إذا كانت بيانات المحتوى المطلوبة من الخادم لا تزال قيد الانتظار ، يتلقى المستخدم صفحة ثابتة معروضة على الفور. يعمل هيكل التطبيق المركزي كتطبيق رئيسي لتطبيقات الصفحة الواحدة التي أنشأتها الفرق المختلفة.
بغض النظر عن المكتبة أو إطار العمل الذي يتم استخدامه ، تتيح الأطر الوصفية دمج الصفحات المختلفة في صفحة واحدة.
التركيب
التركيب هو عملية ترتيب القطع لتلائم المساحات المناسبة على الصفحة. في معظم الحالات ، لا يقوم الفريق الذي ينشر الصفحة بجلب محتوى الجزء على الفور.
بدلاً من ذلك ، فإنه يضع عنصرًا نائبًا أو علامة في المكان الذي يجب أن يكون فيه الجزء في الترميز.
باستخدام عملية تكوين مختلفة ، يتم الانتهاء من التجميع النهائي. يمكن تقسيم التكوين إلى فئتين أساسيتين: جانب العميل وجانب الخادم.
تكوين جانب العميل: يتم استخدام متصفح الويب لإنشاء وتحرير ترميز HTML. كل واجهة أمامية صغيرة لها القدرة على تغيير وإظهار ترميزها بشكل منفصل عن باقي الصفحة.
مكونات الويب ، على سبيل المثال ، تسمح لك بتنفيذ هذا النوع من البناء.
تتمثل الخطة في تحويل كل جزء إلى مكون ويب يمكن تثبيته بشكل مستقل كملف a.js ، وبعد ذلك يمكن للتطبيقات تحميلها وعرضها في المساحات المخصصة لها في تخطيط السمة.
تعتمد مكونات الويب على HTML و DOM API ، والتي يمكن لأطر الواجهة الأمامية الأخرى استخدامها ، بالإضافة إلى طريقة قياسية لإرسال البيانات واستلامها عبر الدعائم والأحداث.
تكوين جانب الخادم: باستخدام هذا التصميم ، يتم دمج أجزاء واجهة المستخدم على الخادم ، مما يؤدي إلى إرسال صفحة مكونة بالكامل إلى جانب العميل ، مما يؤدي إلى تسريع التحميل.
غالبًا ما يتم التجميع بواسطة خدمة منفصلة تقع بين متصفح الويب وخوادم الويب. CDN هو مثيل واحد للخدمة (شبكة توصيل المحتوى).
يمكنك اختيار واحد أو مجموعة من الاثنين ، حسب احتياجاتك.
أنماط الاتصال الصغيرة للواجهة الأمامية
تعمل بنية الواجهة الدقيقة بشكل أفضل عندما يكون هناك تفاعل ضئيل أو معدوم بين المكونات المختلفة. تحتاج الواجهات الصغيرة أحيانًا إلى التحدث مع بعضها البعض ومشاركة المعلومات. فيما يلي بعض الأنماط المحتملة التي قد تؤدي إلى ذلك.
- عمال الويب: العامل عبر الإنترنت هو آلية تمكن محتوى الويب من تشغيل JavaScript في الخلفية ، بشكل مستقل عن البرامج النصية الأخرى ، ودون التأثير على سرعة الصفحة. سيتم توفير واجهة برمجة تطبيقات عاملة فريدة لكل تطبيق صغير. هذه الميزة هي أن العمل الذي يستغرق وقتًا طويلاً يمكن إجراؤه في سلسلة مختلفة ، مما يمكّن مؤشر ترابط واجهة المستخدم من المتابعة دون إبطاء أو توقف.
- باعث الحدث: في هذه الحالة ، تتواصل العديد من المكونات مع بعضها البعض من خلال الاستماع إلى أي تغييرات حالة في المكونات التي اشتركت فيها والعمل عليها. تستجيب الواجهات الصغيرة الأخرى التي اشتركت في هذا الحدث المحدد عندما تطلق واجهة صغيرة هذا الحدث. يجعل باعث الحدث الذي تم إدخاله في كل واجهة أمامية صغيرة هذا الأمر ممكنًا.
- الاسترجاعات والدعائم: في هذا القسم ، تقوم بتعريف المكون الرئيسي والمكونات الفرعية. يتم تنظيم الاتصال في هيكل يشبه الشجرة. تستخدم المكونات الأصلية الدعائم لنقل البيانات كوظائف أسفل شجرة المكونات إلى المكونات الفرعية. في المقابل ، يمكن للطفل تنبيه الوالد بكفاءة عند حدوث أي شيء في حالتهم من خلال الرد على عمليات الاسترجاعات. تستخدم React هذا الوضع.
إيجابيات Micro frontend
التطوير في فرق الحكم الذاتي السريع
يمكن لفريق مستقل إنشاء كل جزء من تطبيق الويب أو موقع الويب عند استخدام طريقة الواجهة الأمامية الدقيقة.
كل فريق مستقل تمامًا ، مما يعني أنه مسؤول عن دورة تطوير المكونات بأكملها ، من المفهوم إلى الإصدار وما بعد الإنتاج.
بالإضافة إلى ذلك ، فإنه يعني أنه يمكن للفرق المختلفة التعاون بسلاسة أثناء العمل في نفس المشروع في نفس الوقت.
لذلك ، تكون دورات التحرير أسرع بكثير مما ستكون عليه مع متراصة الواجهة الأمامية.
تؤدي قواعد التشفير الأصغر للواجهات الدقيقة الفردية إلى كود أكثر نظافة
تحتوي الواجهات الأمامية المتجانسة على قواعد أكواد كبيرة غير عملية تصبح فوضوية بشكل متزايد وصعبة في إدارتها بمرور الوقت.
واجهات صغيرة لمعالجة هذه المشكلة. كل شفرة مصدر لواجهة صغيرة يمكن التحكم فيها لأنها أصغر وأبسط وأكثر إحكاما.
يستفيد حل الويب الشامل من كود أنظف كنتيجة لذلك.
استقرار محسّن للتطبيق بسبب اقتران فضفاض
نادرًا ما يمكن تقسيم حل الويب إلى أجزاء مستقلة تمامًا. وبالتالي ، فإن الواجهات الأمامية الصغيرة تتحدث مع بعضها البعض.
ومع ذلك ، فإن كل رابط بين المكونات مهم على الرغم من ضعف الاتصال.
فشل أحد المكونات له تأثير ضئيل أو معدوم على تشغيل جميع المكونات الأخرى ، مما يوفر الاستقرار المعزز لحل الويب.
أصبح اختبار الميزات الفردية أكثر بساطة
هذه الفائدة ناتجة عن خصائص الواجهات الصغيرة. بناءً على هذا التصميم المعماري ، يكون جانب عميل حل الويب معياريًا وكل وحدة مستقلة.
ونتيجة لذلك ، فإن تقييم جزء صغير من واجهة المستخدم في حد ذاته أسهل على الفريق من القيام به من اختبار كتلة ضخمة.
يؤدي حجم الحزمة المنخفض إلى تحميل أسرع للصفحة
أحد الأسباب الرئيسية لتأخر أوقات التحميل في أنظمة الويب المتجانسة الغنية بالميزات هو حجم حزمة JavaScript. على الجانب الآخر ، يسهّل نهج الواجهة الأمامية المصغرة تقليل وقت تحميل الصفحة.
لا يتعين على المستعرض تنزيل التعليمات البرمجية غير الضرورية بشكل متكرر نظرًا لأن صفحة الويب تتكون من عدة حزم صغيرة. نتيجة لذلك ، يتم زيادة أداء الصفحة وأوقات التحميل.
استقلالية التكنولوجيا
قد يؤدي إجراء الأطر الأمامية يمكن للمطورين استخدامها لإنشاء حل واحد عبر الإنترنت بهندسة واجهة مصغرة.
نظرًا لأن كل مكون مستقل ، يمكن بناؤه باستخدام أي تقنية تناسب مهام الفريق بشكل أفضل.
بطبيعة الحال ، يجب على المبرمجين توخي الحذر عند اختيار أطر عمل لمشروع البرنامج الذي يتولون مسؤوليته ، ولا يزال يُنصح بشدة بالتشاور مع الفرق الأخرى.
ومع ذلك ، لا توجد فرصة لإجبارك على استخدام إطار عمل قديم طوال مدة عمر التطبيق.
سلبيات Micro Frontend
اختبار حل الويب المعقد بالكامل
يعد اختبار الوحدات النمطية المختلفة لحل الويب أمرًا سهلاً عندما يستخدم بنية الواجهة الأمامية الدقيقة. ومع ذلك ، فإنه يختلف عن تقييم تطبيق الويب ككل.
تحقق من أن جميع الأجزاء تعمل على النحو المنشود قبل المتابعة. قد يكون هذا صعبًا نظرًا لأن الواجهات الأمامية الصغيرة تعمل بشكل مستقل ولها عمليات تسليم منفصلة.
استثمارات أولية باهظة الثمن
تتطلب مشاريع الواجهة الأمامية الصغيرة عادةً نفقات مالية كبيرة. يعد تجميع العديد من فرق الواجهة الأمامية والاحتفاظ بها مكلفًا.
بالإضافة إلى ذلك ، ستحتاج إلى موظفين إداريين لتنظيم الوظيفة ، والتأكد من تنسيق كل شيء ، وضمان التواصل الممتاز مع الفريق.
تعقيد التطوير والنشر
يمكن أن تصبح إجراءات التطوير والنشر أكثر تعقيدًا نتيجة لتصميم الواجهة الأمامية الصغيرة.
يمكن أن يكون الحل مليئًا بالعديد من المكونات من قبل فرق التطوير المستقلة التي تعمل في نفس المشروع ، على سبيل المثال ، مما قد يتسبب في حدوث مشكلات في مرحلة النشر.
كما أن التجميع الصحيح لجميع الوحدات وتكاملها السلس في المخطط العام ليس بالأمر السهل دائمًا ؛ يتطلب هذا العمل عادةً فهماً شاملاً لجميع التبعيات.
مشاكل الحفاظ على الترابط في تجربة المستخدم
يعد الحفاظ على واجهة مستخدم متسقة أمرًا صعبًا عندما تعمل الفرق بشكل منفصل على عدة أجزاء من البرنامج.
يجب مشاركة حل الويب من قبل جميع مطوري المشروع. خلاف ذلك ، يمكن أن يكون هناك الكثير من التناقضات على طول الطريق.
وفي الختام
يمكن للواجهات الصغيرة ، وهي تصميم معماري معاصر ، أن تعزز بشكل كبير أداء مشاريع تطوير الويب القائمة على الخدمات المصغرة واسعة النطاق.
إنها تمكن المبرمجين من تقسيم الحل الكامل إلى أجزاء منفصلة يمكن إنشاؤها بواسطة عدة فرق مستقلة. يتبع ذلك العديد من الفوائد ، بما في ذلك طرح الميزات بشكل أسرع واختبار أسهل للوحدات الفردية وترقيات أكثر سلاسة.
ولكن هناك بعض الصعوبات مع الواجهات الصغيرة أيضًا.
قد يكون الاختبار الشامل للتطبيق ، على سبيل المثال ، صعبًا.
بالإضافة إلى ذلك ، نظرًا لضرورة وجود فريق كبير من المهندسين والإداريين ، فإن مشاريع الواجهة الأمامية الصغيرة باهظة الثمن.
وبالتالي ، قبل اتخاذ قرار ، يجب أن تأخذ في الاعتبار جميع مكونات دراسة الجدوى الخاصة بك.
فلاديمير كاماج
بطريقة ما لم أفهم على أي مبدأ يعمل التواصل بين المكونات الفردية على الواجهة الأمامية. لا أفهم كيف تريد توصيل المكونات التي تم إنشاؤها في أطر عمل مختلفة. لا يوجد شيء في المقال حول هذا الموضوع. يبدو لي نظام الأحداث والمستمعين كالجحيم على الأرض. كيف ينبغي لنا أن نتصور ذلك؟