تخطَّ إلى المحتوى

Backends for Frontends

نمط BFF — واجهة خلفية مخصصة لكل عميل Backends for Frontends

BFF بوابة API منفصلة لكل نوع عميل (جوال، ويب، شركاء) بدل بوابة عامة واحدة تحاول إرضاء الجميع.

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

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

الصياغة

mobile-app → mobile-bff → { services }
web-app    → web-bff    → { services }

📄 مثال

// mobile-bff — استجابة مختصرة
app.get('/order/:id', async (req, res) => {
  const order = await orderService.get(req.params.id);
  res.json({ id: order.id, status: order.status, total: order.total });
});

// web-bff — استجابة أوسع لنفس الطلب
app.get('/order/:id', async (req, res) => {
  const [order, shipment] = await Promise.all([
    orderService.get(req.params.id),
    shippingService.getByOrder(req.params.id),
  ]);
  res.json({ order, shipment, timeline: buildTimeline(order, shipment) });
});

أهم النقاط

العنصرالوظيفة
بوابة لكل نوع عميلمصممة خصيصاً لشكل البيانات الذي يحتاجه عميل واحد فقط
استقلالية التطويرفريق الجوال يعدّل mobile-bff دون التأثير على واجهة الويب

💡 نصائح عملية

  • أنشئ BFF فقط عندما تتعارض فعلاً احتياجات العملاء — لا تنشئه افتراضياً
  • اجعل كل BFF رقيقاً قدر الإمكان: تجميع وتحويل شكل بيانات، لا منطق أعمال جديد

⚠️ أخطاء شائعة

  • إنشاء BFF منفصل لعميلين يعرضان نفس البيانات بنفس الشكل تقريباً
  • تكرار نفس منطق التحقق والمصادقة في كل BFF بدل مشاركته عبر مكتبة أو طبقة مشتركة

خصائص ذات صلة

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار MICROSERVICES الكامل بالعربي.