درک الگوی Backend برای Frontend (BFF): یک راهنمای ساده

در معماری میکروسرویس‌ها، سیستم‌های ما به ده‌ها سرویس کوچک و متمرکز تقسیم می‌شوند - مانند یک سرویس کاربر، یک سرویس سفارش و یک سرویس محصول.

اما وقتی نوبت به نمایش این اطلاعات به کاربران می رسد، دستگاه های مختلف نیازهای بسیار متفاوتی دارند. یک مرورگر وب روی یک رایانه رومیزی پرسرعت، داشبورد غنی پر از جداول، ستون‌های کناری و نمودارها می‌خواهد. یک برنامه تلفن همراه در یک شبکه سلولی کند می خواهد یک طرح ساده و سبک وزن برای صرفه جویی در پهنای باند و باتری داشته باشد. یک برنامه ساعت هوشمند ممکن است فقط به یک خط متن نیاز داشته باشد.

اگر همه این فرانت‌اندها دقیقاً همان API باطنی را پرس و جو کنند، کسی باید مصالحه کند. یا برنامه تلفن همراه مجبور به دانلود حجم عظیمی از داده های بی فایده می شود، یا برنامه وب مجبور می شود ده ها درخواست شبکه جداگانه برای واکشی هر چیزی که نیاز دارد انجام دهد.

این دقیقاً مشکلی است که با الگوی Backend for Frontend (BFF) حل شده است. در این راهنما، این الگو را با کلمات ساده توضیح می دهیم، به یک قیاس در دنیای واقعی نگاه می کنیم، آن را با یک API Gateway استاندارد مقایسه می کنیم، و پیاده سازی کد عملی را طی می کنیم.

قیاس دنیای واقعی: منوی رستوران

رستورانی را تصور کنید که سه نوع غذاخوری بسیار متفاوت سرو می کند:

1. یک منتقد غذا که می خواهد یک منوی کامل 5 غذای مزه با لیست مواد تشکیل دهنده دقیق داشته باشد.
2. یک مسافر شلوغ که می خواهد یک میان وعده سریع و از پیش بسته بندی شده برای خوردن در قطار بخورد.
3. کودکی که یک غذای ساده بچه گانه با وعده های کوچک و بدون مواد تند می خواهد.

اگر رستوران فقط یک منوی واحد داشت که هر سه گزینه را با جزئیات کامل ذکر می کرد، بسیار زیاد بود. مسافر با خواندن دستور العمل های 5 دوره ای وقت خود را تلف می کند و والدین کودک برای یافتن گزینه های غذایی ساده با مشکل مواجه می شوند.

در عوض، رستوران سه منوی سفارشی را چاپ می کند: یک منوی مزه، یک منوی سریع برای رفتن، و یک منوی کودکان.

هر منو از یک آشپزخانه (سرویس های میکرو) تهیه می شود، اما انتخاب ها را به طور خاص برای آن مشتری (مشتری) قالب بندی و اندازه می کند.

در این سناریو:

• آشپزخانه نشان دهنده خدمات میکرو شما (کاربر، کاتالوگ، پرداخت) است.
• منوهای سفارشی BFFهای شما هستند (Web BFF، Mobile BFF، Watch BFF).
• ** ناهارخوری ها ** پیشانی ** شما هستند (مرورگر دسکتاپ، برنامه موبایل، ساعت هوشمند).

مشکل: API “One-Size-Fits-All”.

هنگامی که میکروسرویس ها برای اولین بار محبوب شدند، بسیاری از تیم ها یک API Gateway واحد و مشترک را برای مدیریت تمام مشتریان فرانت اند ساختند:

در حالی که یک نقطه ورودی واحد عالی است، یک API مشترک چندین گلوگاه مقیاس بندی را معرفی می کند:

• Payload Bloat برای موبایل: برنامه وب دسکتاپ به تاریخچه سفارش کاربر، آدرس صورتحساب، تصویر نمایه و امتیازات وفاداری نیاز دارد. برنامه تلفن همراه فقط باید «آخرین سفارش: ارسال شده» را نشان دهد. با یک API مشترک، برنامه تلفن همراه کل محموله نمایه را دانلود می‌کند، داده‌های ارزشمند را هدر می‌دهد و زمان بارگذاری را کاهش می‌دهد.
• ** تنگناهای API**: یک تیم به گلوگاه دروازه مشترک تبدیل می شود. اگر تیم iOS می‌خواهد یک فیلد طرح‌بندی کوچک را تغییر دهد، باید منتظر بمانند تا تیم دروازه مشترک نسخه جدیدی را اجرا کند و چرخه‌های توسعه را کندتر کند.
• نیازهای امنیتی مختلف: یک مرورگر وب ممکن است به جلسات مبتنی بر کوکی برای جلوگیری از اسکریپت بین سایتی (XSS) نیاز داشته باشد، در حالی که یک برنامه تلفن همراه سرصفحه های OAuth مبتنی بر توکن را ترجیح می دهد. مدیریت هر دو در یک سرور واحد کد پیچیده و نامرتب ایجاد می کند.

راه حل: الگوی BFF

الگوی BFF به جای ایجاد یک دروازه غول پیکر برای همه دستگاه ها، از ساخت یک سرور باطن اختصاصی برای هر برنامه فرانت اند دفاع می کند.

شما خواهید داشت:

• Web BFF: به درخواست های مرورگر دسکتاپ رسیدگی می کند. نمایه های کامل، کاتالوگ محصولات و اطلاعات دقیق پرداخت را جمع آوری می کند.
• Mobile BFF: به درخواست های برنامه های iOS و Android رسیدگی می کند. داده ها را جمع می کند، فیلدهای غیر ضروری را فیلتر می کند و پاسخ نهایی را فشرده می کند تا عملکرد سریع را تضمین کند.

دروازه API در مقابل BFF: تفاوت چیست؟

اشتباه گرفتن این دو الگو معمول است زیرا هر دو بین مشتری و میکروسرویس قرار می گیرند. در اینجا تمایز وجود دارد:

یک پیاده سازی عملی (Node.js/Express)

برای درک اینکه چگونه این در عمل کار می کند، اجازه دهید یک مثال ساده Node.js بنویسیم.

تصور کنید ما دو میکروسرویس به صورت داخلی داریم:

• سرویس کاربر (اطلاعات اولیه نمایه کاربر را برمی گرداند)
• خدمات سفارش (لیستی از سفارشات را با جزئیات کامل برمی گرداند)

ما می‌خواهیم یک Web BFF و یک Mobile BFF بسازیم تا به سایت دسکتاپ و برنامه تلفن همراه ما به شکلی متفاوت خدمت کند.

1. Microservices Mock مشترک

اول، در اینجا داده های ساختگی برای دو میکروسرویس اساسی ما آمده است:

// 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. 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'));

مقایسه اندازه بار

• اندازه پاسخ وب BFF: شامل پیکربندی تودرتو، تنظیمات برگزیده، فهرست کامل سفارش، مالیات، موارد و غیره (تقریباً 400 بایت).
• اندازه پاسخ BFF موبایل: فقط شامل 6 جفت کلید-مقدار است که نشان دهنده موارد ضروری است. (تقریباً 120 بایت—70٪ کاهش در اندازه شبکه!).

مزایا و معایب الگوی BFF

در حالی که الگوی BFF بسیار موثر است، معاوضه هایی نیز دارد:

نتیجه گیری

الگوی Backend for Frontend (BFF) یک معماری قدرتمند برای سیستم‌هایی است که انواع سرویس گیرنده‌های مختلف مانند دستگاه‌های وب، موبایل و اینترنت اشیا را ارائه می‌کنند. با ایجاد دروازه های مناسب برای هر فرانت اند خاص، توسعه مشتری را از هم جدا می کنید، حجم بار را به حداقل می رسانید و تجربه کاربری سریعتر و پاسخگوتر را ارائه می دهید.

اگر سیستم شما فقط یک برنامه وب دارد، یک API Gateway مشترک کافی است. اما از لحظه‌ای که شروع به ساخت اپلیکیشن‌های تلفن همراه یا تجربه‌های تخصصی دستگاه در کنار برنامه وب خود می‌کنید، پیاده‌سازی BFF بهترین راه برای تمیز، بهینه‌سازی و مستقل ماندن معماری‌های ظاهری و بک‌اند شما است.

درباره توسعه نرم‌افزار بیشتر و بینش‌های مهندسی باطن در Ghaznix Blog →