الفرق بين BFF وAPI Gateway: متى تستخدم كل منهما

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

إنهما ليسا متنافسين. الواجهة الخلفية للواجهة الأمامية (BFF) وبوابة API تحلان مشكلات مختلفة، ويمتلكهما فرق مختلفة، وغالبًا ما يعملان معًا في نفس النظام. يجلس الـ BFF خلف البوابة أو بجانبها، وليس بدلاً منها.

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

ما هي بوابة API؟

بوابة API هي نقطة دخول مركزية تقع بين العملاء وخدماتك الخلفية. يأتي كل طلب عبر البوابة، والتي تطبق مجموعة متسقة من الاهتمامات الشاملة قبل توجيه المكالمة.

تلك الاهتمامات هي نفسها لكل عميل وكل خدمة:

• التوجيه: مطابقة مسار وارد مع الخدمة النهائية الصحيحة.
• المصادقة والتفويض: التحقق من صحة الرموز، ورفض المتصلين غير المصرح لهم.
• تحديد المعدل والتحكم فيه: حماية الواجهات الخلفية من الحمل الزائد وسوء الاستخدام.
• قابلية الملاحظة: تسجيل الطلبات، إصدار المقاييس، تتبع المكالمات عبر الخدمات.
• إنهاء TLS، التخزين المؤقت، وتحويل الطلبات: التعامل مع البنية التحتية مرة واحدة، في مكان واحد.

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

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

ما هي الواجهة الخلفية للواجهة الأمامية (BFF)؟

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

القاعدة الأساسية لنيومان هي "تجربة واحدة، BFF واحد". الواجهات الأمامية المختلفة بشكل كبير تحصل على BFF الخاص بها؛ ويمكن للمتشابهة منها (مثل تطبيق iOS وتطبيق Android يديرهما نفس الفريق) مشاركة BFF واحد.

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

ماذا يفعل الـ BFF بالفعل؟ إنه يشكل البيانات لعميل واحد:

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

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

أين يتداخل BFF وبوابة API

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

التداخل حقيقي ولكنه سطحي. يكمن الاختلاف في القصد والملكية:

• بوابة API تجمع وتوجه بشكل عام، لجميع العملاء، لتركيز السياسة.
• الـ BFF يجمع ويوجه بشكل خاص، لواجهة أمامية واحدة، لتحسين تجربة هذا العميل.

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

إذن، الحدود العملية هي هذه: إذا كانت المسؤولية هي نفسها لكل عميل، فإنها تنتمي إلى البوابة. إذا تغيرت لكل واجهة أمامية، فإنها تنتمي إلى الـ BFF.

BFF وبوابة API يعملان معًا

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

يبدو تدفق الطلب النموذجي كالتالي:

1. يرسل العميل المحمول طلبًا مع رمز المصادقة الخاص به.
2. تقوم بوابة API بالتحقق من صحة الرمز، وتفرض حدود المعدل، وتسجل الطلب للمراقبة، ثم توجيهه إلى الـ BFF المحمول.
3. يقوم الـ BFF المحمول باستدعاء خدمة المنتج، وخدمة المخزون، وخدمة التسعير، ويجمع النتائج، ويقلل الحمولة إلى ما تحتاجه شاشة الجوال، ويعيد استجابة واحدة.
4. تقوم البوابة ببث الاستجابة مرة أخرى إلى العميل.

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

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

علاقة الطبقات هذه تشبه كيفية تعايش البوابة مع البنى التحتية الأخرى بدلاً من استبدالها. البوابة ليست موازن تحميل (بوابة API مقابل موازن التحميل) وليست شبكة خدمات (شبكة الخدمات مقابل بوابة API) أيضًا؛ كل منهما يتعامل مع طبقة مميزة من مسار الطلب، والـ BFF هو مجرد طبقة مميزة أخرى. إنه نفس المبدأ وراء الاتصال الموجه بواجهة API: أعطِ كل طبقة مهمة واضحة ودعها تفعل ذلك فقط.

جدول القرارات: BFF مقابل بوابة API

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

متى تستخدم أيًا منهما

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

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

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

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

استخدم كليهما عندما تدير الخدمات المصغرة على نطاق واسع: البوابة للسياسة الموحدة على الحافة، و الـ BFFs خلفها لتشكيل خاص بالعميل. هذه هي الحالة النهائية الشائعة، وليست غريبة.

الأخطاء الشائعة

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

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

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

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

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

أين يتناسب Apidog

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

بشكل ملموس:

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

النمط الذي تختاره هو قرار معماري. العقد الذي تكشف عنه كل طبقة هو ثابت. يتعامل Apidog مع الثابت، لذلك تظل BFFs والبوابات الخاصة بك مصممة ومختبرة ومحاكاة وموثقة بغض النظر عن كيفية توصيلها.

جرب Apidog مجانًا لتصميم ومحاكاة عقود BFF والبوابة الخاصة بك قبل كتابة سطر واحد من التعليمات البرمجية الخلفية.

الأسئلة الشائعة

هل BFF نوع من بوابة API؟ لا. يتداخلان في أن كليهما يمكنه التوجيه والتجميع، لكن الـ BFF يمتلكه فريق الواجهة الأمامية ويصمم خصيصًا لتجربة عميل واحدة، بينما بوابة API مملوكة مركزيًا وتخدم جميع العملاء بشكل موحد. عادةً ما يجلس الـ BFF خلف بوابة.

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

كم عدد الـ BFFs التي يجب أن أمتلكها؟ اتبع قاعدة سام نيومان "تجربة واحدة، BFF واحد". قم ببناء BFF منفصل لكل واجهة أمامية مختلفة بشكل كبير. يمكن للعملاء المتشابهين الذين يديرهم نفس الفريق، مثل تطبيقات iOS و Android، مشاركة BFF واحد.

هل يحل BFF محل بوابة API الخاصة بي؟ لا. إنهما طبقتان متكاملتان. تفرض البوابة سياسة موحدة عند الحافة؛ بينما يشكل الـ BFF البيانات لعميل معين خلفها. معظم أنظمة الخدمات المصغرة الحقيقية تشغل كليهما.

متى لا ينبغي لي بناء BFF؟ تجاوزها عندما يقوم جميع العملاء بإجراء طلبات مماثلة، أو عندما يوجد عميل واحد فقط، أو عندما تسمح طبقة GraphQL مع محللات خاصة بالواجهة الأمامية للعملاء بالفعل بجلب البيانات التي يحتاجونها بالضبط.

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