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

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

جرّب Apidog اليوم

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

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

ما هي بوابة API؟

بوابة API هي نقطة دخول مركزية بين العملاء والخدمات الخلفية. كل طلب يمر عبرها قبل الوصول إلى الخدمة المناسبة.

استخدم البوابة للمهام المشتركة بين كل العملاء والخدمات:

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

مثال عملي لتدفق عبر البوابة:

Client
  -> API Gateway
      -> Auth validation
      -> Rate limit
      -> Logging / tracing
      -> Route to service
  -> Product Service

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

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

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

الواجهة الخلفية للواجهة الأمامية Backend for Frontend - BFF هي خدمة خلفية مصممة لتجربة مستخدم واحدة. بدلًا من واجهة خلفية عامة لكل العملاء، تنشئ BFF للويب، وBFF للجوال، وربما BFF للوحة الإدارة إذا كانت احتياجاتها مختلفة.

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

القاعدة العملية لسام نيومان:

تجربة واحدة، BFF واحد.

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

ما يفعله BFF عمليًا:

• تجميع البيانات: شاشة واحدة تحتاج بيانات من خدمات متعددة.
• تقليل الحمولة: الجوال يحتاج 3 حقول فقط بدلًا من 40.
• إعادة تشكيل الاستجابة: تحويل بيانات الخدمات إلى شكل مناسب لواجهة واحدة.
• تنسيق خاص بالعميل: الويب قد يحتاج بيانات غنية، والجوال يحتاج استجابة أخف.

مثال:

Mobile App
  -> Mobile BFF
      -> Product Service
      -> Inventory Service
      -> Pricing Service
  -> Aggregated mobile response

مثال استجابة BFF مخصصة للجوال:

{
  "id": "p_123",
  "name": "Wireless Keyboard",
  "price": 49.99,
  "inStock": true
}

بدون BFF، قد يضطر العميل لاستدعاء عدة خدمات ثم دمج النتائج محليًا:

Mobile App
  -> Product Service
  -> Inventory Service
  -> Pricing Service

هذا يزيد عدد الرحلات الشبكية ويجعل الواجهة الأمامية تعرف تفاصيل كثيرة عن بنية الخدمات الداخلية.

يمكن اعتبار BFF نوعًا متخصصًا من مجمع API، لكنه ليس طبقة عامة؛ هو مجمع مخصص لعميل أو تجربة واحدة.

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

الالتباس منطقي لأن النمطين يبدوان متشابهين في الرسوم المعمارية:

Client -> Box -> Services

كلاهما يمكنه:

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

لكن الفرق ليس في الشكل، بل في القصد والملكية:

• بوابة API تجمع وتوجه بشكل عام لكل العملاء، بهدف فرض السياسة.
• BFF يجمع ويشكل البيانات لواجهة واحدة، بهدف تحسين تجربة ذلك العميل.

قاعدة قرار سريعة:

هل هذه المسؤولية متطابقة لكل العملاء؟
  نعم -> API Gateway
  لا، تختلف حسب الواجهة -> BFF

أمثلة:

المسؤولية	المكان الصحيح
التحقق من JWT	بوابة API
تحديد المعدل لكل عميل	بوابة API
تسجيل الطلبات وتتبعها	بوابة API
دمج بيانات المنتج والمخزون لشاشة جوال	BFF
حذف الحقول غير المطلوبة لتطبيق الجوال	BFF
تغيير شكل الاستجابة حسب تجربة الويب	BFF

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

كيف يعمل BFF وبوابة API معًا؟

في نظام خدمات مصغرة حقيقي، لا تختار غالبًا بينهما. تشغلهما كطبقات:

Client
  -> API Gateway
      -> BFF
          -> Microservices

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

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

مثال تدفق:

Mobile App
  -> API Gateway
      -> validate token
      -> apply rate limit
      -> log request
      -> route /mobile/products/:id
  -> Mobile BFF
      -> Product Service
      -> Inventory Service
      -> Pricing Service
  -> API Gateway
  -> Mobile App

بهذا التقسيم:

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

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

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

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

استخدم الجدول كسؤال توجيهي للمسؤوليات:

نفس السلوك لكل عميل -> Gateway
سلوك مختلف لكل تجربة -> BFF
نحتاج الاثنين -> Gateway + BFF

متى تستخدم بوابة API؟

استخدم بوابة API عندما يكون لديك:

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

مثال:

/api/products/*  -> Product Service
/api/orders/*    -> Order Service
/api/users/*     -> User Service

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

متى تستخدم BFF؟

استخدم BFF عندما تختلف احتياجات العملاء بشكل حقيقي.

محفزات شائعة:

• تطبيق الجوال يحتاج حمولة صغيرة جدًا.
• تطبيق الويب يحتاج بيانات غنية ومركبة.
• واجهة خلفية عامة أصبحت مليئة بشروط مثل if mobile وif web.
• فريق الواجهة الأمامية ينتظر تغييرات خلفية بسيطة باستمرار.
• العميل يضطر لاستدعاء عدة خدمات لبناء شاشة واحدة.

مثال على مؤشر سيئ داخل API عامة:

if (clientType === "mobile") {
  return compactProductResponse(product);
}

if (clientType === "web") {
  return detailedProductResponse(product);
}

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

متى تتجنب BFF؟

لا تبنِ BFF فقط لأنه نمط شائع. تجنبه عندما:

• لديك عميل واحد فقط.
• كل العملاء يحتاجون نفس البيانات تقريبًا.
• واجهة API مشتركة واحدة تخدم كل الحالات جيدًا.
• تكلفة خدمة إضافية، نشر إضافي، ومراقبة إضافية لا تبرر الفائدة.
• طبقة GraphQL مع محللات مناسبة تتيح لكل واجهة طلب الحقول المطلوبة بدقة.

BFF يضيف:

• قفزة شبكة إضافية.
• خدمة جديدة للنشر والمراقبة.
• عقود API إضافية.
• احتمال تكرار منطق بين BFFs مختلفة.

إذا لم تكن هناك اختلافات حقيقية بين العملاء، فسيكون BFF عبئًا معماريًا زائدًا.

متى تستخدم الاثنين معًا؟

استخدم الاثنين عندما تدير خدمات مصغرة على نطاق عملي وتملك عملاء مختلفين فعلًا.

النمط الشائع:

Web App
  -> API Gateway
      -> Web BFF
          -> Services

Mobile App
  -> API Gateway
      -> Mobile BFF
          -> Services

تقسيم المسؤوليات:

API Gateway:
- Auth
- Authorization
- Rate limit
- Routing
- Observability
- TLS termination

BFF:
- Aggregation
- Response shaping
- Client-specific orchestration
- Payload reduction

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

أخطاء شائعة

1. وضع المصادقة وتحديد المعدل داخل BFF

هذا هو الخطأ الأكثر شيوعًا.

خطأ:

Mobile BFF -> validates JWT
Web BFF    -> validates JWT differently
Admin BFF  -> has another policy

النتيجة: سياسات أمنية متفرقة وغير متسقة.

الصحيح:

API Gateway -> validates JWT once
BFF         -> handles client-specific shaping

2. السماح لـ BFF بأن يصبح مونوليثًا ثانيًا

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

خطأ:

Mobile BFF
  -> pricing rules
  -> inventory rules
  -> promotion rules
  -> user segmentation

الصحيح:

Mobile BFF
  -> calls Pricing Service
  -> calls Inventory Service
  -> calls Promotion Service
  -> shapes response

3. استخدام البوابة كـ BFF

بعض الفرق تضع تحويلات خاصة بالعميل داخل إعدادات البوابة لتجنب بناء BFF.

هذا قد يعمل مؤقتًا، لكنه يخلق مشكلة ملكية:

• فريق الواجهة يحتاج تغييرًا سريعًا.
• التغيير موجود في البوابة.
• البوابة يملكها فريق المنصة.
• كل تعديل يصبح تذكرة وانتظارًا.

إذا كان التحويل خاصًا بعميل واحد، فهو غالبًا ينتمي إلى BFF.

4. بناء BFF مبكرًا

إذا كان لديك تطبيق ويب واحد فقط، ولا يوجد عميل آخر، لا تبدأ بـ BFF منفصل دون سبب.

ابدأ بواجهة API واضحة. أضف BFF عندما يظهر عميل مختلف فعلًا وتصبح الاحتياجات متباينة.

5. نسيان عقد API

كل BFF وكل مسار في البوابة يكشف API. هذا يعني أنك تحتاج إلى:

• عقد واضح.
• اختبارات.
• محاكاة.
• توثيق.
• أمثلة استجابة.
• قواعد إصدار.

لا تعامل BFF كطبقة “رقيقة” غير موثقة. إذا كان العميل يعتمد عليها، فهي API حقيقية. راجع ما هو عقد API لفهم أهمية ذلك.

أين يتناسب Apidog؟

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

Apidog لا يبني بوابة API ولا يستضيف BFF ولا يستبدلهما. دوره هو إدارة واجهات API التي تكشفها هذه الطبقات.

استخدم Apidog عمليًا في هذه الحالات:

تصميم العقد

صمم استجابة BFF المجمعة أو مسارات البوابة بالاعتماد على المخطط أولًا، ثم شارك OpenAPI مع فرق الواجهة والخلفية.

مثال عقد لاستجابة Mobile BFF:

{
  "productId": "string",
  "title": "string",
  "price": "number",
  "available": "boolean"
}

محاكاة BFF قبل اكتمال الخدمات

يمكن لفريق الجوال تطوير الشاشة اعتمادًا على Mock API قبل اكتمال BFF أو الخدمات الداخلية. هذا يدعم سير عمل API-first ويقلل الانتظار بين الفرق.

اختبار المسارات

ابنِ سيناريوهات اختبار تصل إلى نقاط النهاية كما يفعل العميل الحقيقي:

• تحقق من المصادقة.
• تحقق من رموز الحالة.
• تحقق من شكل الحمولة المجمعة.
• تحقق من الحالات الفارغة والأخطاء.

توثيق واجهات BFF والبوابة

انشر توثيقًا تفاعليًا لكل BFF ومسار Gateway حتى يعرف كل فريق مستهلك العقد دون قراءة التنفيذ.

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

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

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

هل BFF نوع من بوابة API؟

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

هل يمكن استخدام BFF بدون بوابة API؟

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

كم عدد BFFs التي أحتاجها؟

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

هل يحل BFF محل بوابة API؟

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

متى لا ينبغي بناء BFF؟

تجنبه عندما يكون لديك عميل واحد، أو عندما يطلب كل العملاء نفس البيانات تقريبًا، أو عندما تكفي واجهة API مشتركة أو GraphQL لتلبية احتياجات الواجهات بدون طبقة إضافية.

أين تنتمي المصادقة وتحديد المعدل؟

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