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 الكامل بالعربي.