فهم نمط الواجهة الخلفية للواجهة الأمامية (BFF): دليل بسيط

في بنية الخدمات الصغيرة، يتم تقسيم أنظمتنا إلى العشرات من الخدمات الصغيرة المركزة - مثل خدمة المستخدم، وخدمة الطلب، وخدمة المنتج.

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

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

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

القياس على العالم الحقيقي: قائمة المطعم

تخيل مطعمًا يقدم ثلاثة أنواع مختلفة تمامًا من الطعام:

1. ناقد طعام يريد قائمة تذوق كاملة مكونة من 5 أطباق مع قوائم مفصلة بالمكونات.
2. الركاب المزدحمون الذين يريدون تناول وجبة خفيفة سريعة ومعبأة مسبقًا في القطار.
3. الطفل الذي يريد وجبة بسيطة للأطفال تحتوي على أجزاء صغيرة ولا تحتوي على مكونات حارة.

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

بدلاً من ذلك، يطبع المطعم ثلاث قوائم مخصصة: قائمة التذوق، وقائمة الوجبات السريعة، وقائمة الأطفال.

كل قائمة مأخوذة من نفس المطبخ (الخدمات الصغيرة)، ولكنها تقوم بتنسيق الاختيارات وحجمها خصيصًا لذلك العميل (العميل).

في هذا السيناريو:

• المطبخ يمثل خدماتك الصغيرة (المستخدم، الكتالوج، الدفع).
• القوائم المخصصة هي صديقاتك المفضلة (Web BFF، Mobile BFF، Watch BFF).
• الضيوف هم الواجهات الأمامية (متصفح سطح المكتب، تطبيق الهاتف المحمول، الساعة الذكية).

المشكلة: واجهة برمجة التطبيقات “مقاس واحد يناسب الجميع”.

عندما أصبحت الخدمات الصغيرة شائعة لأول مرة، قامت العديد من الفرق ببناء بوابة API مشتركة واحدة للتعامل مع جميع عملاء الواجهة الأمامية:

على الرغم من أن نقطة الدخول الواحدة تعد أمرًا رائعًا، إلا أن واجهة برمجة التطبيقات المشتركة تقدم العديد من اختناقات التوسع:

• Payload Bloat for Mobile: يحتاج تطبيق الويب لسطح المكتب إلى سجل طلبات المستخدم وعنوان إرسال الفواتير وصورة الملف الشخصي ونقاط الولاء. يحتاج تطبيق الهاتف المحمول فقط إلى إظهار “آخر طلب: تم ​​الشحن”. باستخدام واجهة برمجة التطبيقات المشتركة، يقوم تطبيق الهاتف المحمول بتنزيل حمولة الملف الشخصي بالكامل، مما يؤدي إلى إهدار البيانات الثمينة وإبطاء أوقات التحميل.
• اختناقات واجهة برمجة التطبيقات: يصبح الفريق الواحد هو عنق الزجاجة للبوابة المشتركة. إذا أراد فريق iOS تغيير حقل تخطيط صغير، فيجب عليه الانتظار حتى يقوم فريق البوابة المشتركة بنشر إصدار جديد، مما يؤدي إلى إبطاء دورات التطوير.
• الاحتياجات الأمنية المختلفة: قد يتطلب متصفح الويب جلسات تعتمد على ملفات تعريف الارتباط لمنع البرمجة النصية عبر المواقع (XSS)، بينما يفضل تطبيق الهاتف المحمول رؤوس OAuth المستندة إلى الرمز المميز. يؤدي التعامل مع كليهما في خادم واحد إلى إنشاء تعليمات برمجية معقدة وفوضوية.

الحل: نمط BFF

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

سيكون لديك:

• Web BFF: يتعامل مع الطلبات الواردة من متصفح سطح المكتب. يقوم بتجميع الملفات الشخصية الكاملة وكتالوجات المنتجات ومعلومات الدفع التفصيلية.
• Mobile BFF: يتعامل مع الطلبات الواردة من تطبيقات iOS وAndroid. فهو يجمع البيانات، ويصفي الحقول غير الضرورية، ويضغط الاستجابة النهائية لضمان الأداء السريع.

بوابة API مقابل BFF: ما الفرق؟

من الشائع الخلط بين هذين النموذجين لأنهما يقعان بين العميل والخدمات الصغيرة. وهنا التمييز:

التنفيذ العملي (Node.js/Express)

لفهم كيفية عمل ذلك عمليًا، دعنا نكتب مثالًا بسيطًا على Node.js.

تخيل أن لدينا خدمتين صغيرتين تعملان داخليًا:

• خدمة المستخدم (إرجاع معلومات ملف تعريف المستخدم الأساسية)
• خدمة الطلب (إرجاع قائمة الطلبات بالتفاصيل الكاملة)

نريد إنشاء Web BFF وMobile BFF لخدمة موقع سطح المكتب وتطبيق الهاتف المحمول لدينا بشكل مختلف.

1. نموذج الخدمات الصغيرة المشتركة

أولاً، إليك البيانات الوهمية لخدمتين صغيرتين أساسيتين:

// Internal User Service Response
const userProfile = {
    id: 42,
    username: "dev_coder",
    email: "coder@ghaznix.com",
    avatarUrl: "https://ghaznix.com/avatars/42.png",
    preferences: { theme: "light", newsletter: true }
};

// Internal Order Service Response
const orderHistory = [
    { id: "ORD-99", date: "2026-06-25", items: ["Laptop", "Mouse"], status: "Shipped", tax: 15.00, total: 1215.00 },
    { id: "ORD-88", date: "2026-05-12", items: ["Keyboard"], status: "Delivered", tax: 5.00, total: 105.00 }
];

2. Web BFF (إرجاع الحمولة التفصيلية الكاملة)

يقوم Web BFF بتجميع كافة الحقول لأن شاشة سطح المكتب بها مساحة كبيرة لعرضها:

const express = require('express');
const webBff = express();

webBff.get('/dashboard', (req, res) => {
    // Web needs everything: profile + full order details + settings
    const responsePayload = {
        user: {
            username: userProfile.username,
            email: userProfile.email,
            avatar: userProfile.avatarUrl,
            theme: userProfile.preferences.theme
        },
        orders: orderHistory // Send all order details, taxes, and items
    };
    
    res.json(responsePayload);
});

webBff.listen(3001, () => console.log('Web BFF running on port 3001'));

3. Mobile BFF (إرجاع الحمولة المجمعة والمصغرة)

يقوم Mobile BFF بتصفية الحقول غير الضرورية (مثل البريد الإلكتروني والإعدادات والضرائب) ويجمع عناصر الطلب لتوفير النطاق الترددي:

const express = require('express');
const mobileBff = express();

mobileBff.get('/dashboard', (req, res) => {
    // Mobile only wants: username, avatar, and summary of the latest order
    const latestOrder = orderHistory[0];
    
    const responsePayload = {
        user: {
            username: userProfile.username,
            avatar: userProfile.avatarUrl
        },
        latestOrderStatus: {
            orderId: latestOrder.id,
            status: latestOrder.status,
            date: latestOrder.date,
            itemCount: latestOrder.items.length // Send count instead of array list
        }
    };
    
    res.json(responsePayload);
});

mobileBff.listen(3002, () => console.log('Mobile BFF running on port 3002'));

مقارنة حجم الحمولة

• حجم استجابة Web BFF: يحتوي على التكوين المتداخل والتفضيلات وقائمة الطلبات الكاملة والضرائب والعناصر وما إلى ذلك (حوالي 400 بايت).
• حجم استجابة BFF للجوال: يحتوي فقط على 6 أزواج ذات قيمة أساسية تمثل الأساسيات. (حوالي 120 بايت —تخفيض بنسبة 70% في حجم الشبكة!).

إيجابيات وسلبيات نمط BFF

على الرغم من فعاليته العالية، إلا أن نمط BFF له مقايضات:

خاتمة

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

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

استكشف المزيد من الرؤى المتعلقة بتطوير البرامج وهندسة الواجهة الخلفية على مدونة Gaznix →