فرنٹ اینڈ (BFF) پیٹرن کے لیے بیک اینڈ کو سمجھنا: ایک سادہ گائیڈ

مائیکرو سروسز آرکیٹیکچر میں، ہمارے سسٹمز کو درجنوں چھوٹی، فوکسڈ سروسز میں تقسیم کیا جاتا ہے—جیسے صارف کی خدمت، ایک آرڈر سروس، اور ایک پروڈکٹ سروس۔

لیکن جب آپ کے صارفین کو یہ معلومات ظاہر کرنے کی بات آتی ہے تو مختلف آلات کی بہت مختلف ضروریات ہوتی ہیں۔ تیز رفتار ڈیسک ٹاپ کمپیوٹر پر ایک ویب براؤزر ٹیبلز، سائڈ بارز اور گرافس سے بھرا ایک بھرپور ڈیش بورڈ چاہتا ہے۔ سست سیلولر نیٹ ورک پر ایک موبائل ایپ بینڈوتھ اور بیٹری کو بچانے کے لیے ایک سادہ، ہلکا پھلکا لے آؤٹ چاہتی ہے۔ ایک سمارٹ واچ ایپ کو متن کی صرف ایک لائن کی ضرورت ہو سکتی ہے۔

اگر یہ تمام فرنٹ اینڈز بالکل اسی بیک اینڈ API سے استفسار کرتے ہیں تو کسی کو سمجھوتہ کرنا پڑے گا۔ یا تو موبائل ایپ کو بڑی مقدار میں بیکار ڈیٹا ڈاؤن لوڈ کرنے پر مجبور کیا جاتا ہے، یا ویب ایپ کو اپنی ضرورت کی ہر چیز حاصل کرنے کے لیے درجنوں علیحدہ نیٹ ورک کی درخواستیں کرنے پر مجبور کیا جاتا ہے۔

یہ بالکل وہی مسئلہ ہے جسے Backend for Frontend (BFF) پیٹرن نے حل کیا ہے۔ اس گائیڈ میں، ہم اس پیٹرن کی سادہ الفاظ میں وضاحت کریں گے، ایک حقیقی دنیا کی مشابہت کو دیکھیں گے، اس کا ایک معیاری API گیٹ وے سے موازنہ کریں گے، اور کوڈ کے عملی نفاذ کے ذریعے چلیں گے۔

حقیقی دنیا کی تشبیہ: ریستوراں کا مینو

ایک ریستوراں کا تصور کریں جو تین مختلف قسم کے کھانے پیش کرتا ہے:

1. ایک کھانے کا نقاد جو اجزاء کی تفصیلی فہرستوں کے ساتھ مکمل 5 کورس چکھنے والا مینو چاہتا ہے۔
2. ایک مصروف مسافر جو ٹرین میں کھانے کے لیے ایک تیز، پہلے سے پیک شدہ ناشتہ چاہتا ہے۔
3. ایک بچہ جو چھوٹے حصوں اور کوئی مسالیدار اجزاء کے ساتھ ایک سادہ بچے کا کھانا چاہتا ہے۔

اگر ریستوراں میں صرف ایک واحد مینو تھا جس میں تینوں آپشنز کو مکمل تفصیل کے ساتھ درج کیا گیا ہو، تو یہ زبردست ہوگا۔ مسافر 5 کورس کی ترکیبیں پڑھنے میں وقت ضائع کرے گا، اور بچے کے والدین کھانے کے آسان اختیارات تلاش کرنے کے لیے جدوجہد کریں گے۔

اس کے بجائے، ریستوراں تین حسب ضرورت مینو پرنٹ کرتا ہے: ایک چکھنے کا مینو، ایک ایکسپریس ٹو گو مینو، اور بچوں کا مینو۔

ہر مینو ایک ہی کچن (مائیکرو سروسز) سے آتا ہے، لیکن خاص طور پر اس گاہک (کلائنٹ) کے لیے انتخاب کو فارمیٹ اور سائز بناتا ہے۔

اس منظر نامے میں:

• باورچی خانے آپ کی مائیکرو سروسز (صارف، کیٹلاگ، ادائیگی) کی نمائندگی کرتا ہے۔
• حسب ضرورت مینو آپ کے BFFs ہیں (ویب BFF، موبائل BFF، واچ BFF)۔
• ڈنر آپ کے فرنٹنڈز ہیں (ڈیسک ٹاپ براؤزر، موبائل ایپ، اسمارٹ واچ)۔

مسئلہ: “One-size-fits-all” API

جب مائیکرو سروسز پہلی بار مقبول ہوئیں، تو بہت سی ٹیموں نے تمام فرنٹ اینڈ کلائنٹس کو سنبھالنے کے لیے ایک واحد، مشترکہ API گیٹ وے بنایا:

جب کہ ایک داخلی نقطہ بہت اچھا ہے، ایک مشترکہ API کئی پیمانے پر رکاوٹیں متعارف کراتی ہے:

• موبائل کے لیے پے لوڈ بلوٹ: ڈیسک ٹاپ ویب ایپ کو صارف کی آرڈر ہسٹری، بلنگ ایڈریس، پروفائل تصویر، اور لائلٹی پوائنٹس کی ضرورت ہوتی ہے۔ موبائل ایپ کو صرف “آخری آرڈر: بھیج دیا گیا” دکھانے کی ضرورت ہے۔ ایک مشترکہ API کے ساتھ، موبائل ایپ پورے پروفائل پے لوڈ کو ڈاؤن لوڈ کرتی ہے، قیمتی ڈیٹا کو ضائع کرتی ہے اور لوڈ کے اوقات کو کم کرتی ہے۔ *API رکاوٹیں: ایک واحد ٹیم مشترکہ گیٹ وے کے لیے رکاوٹ بن جاتی ہے۔ اگر iOS ٹیم ایک چھوٹے سے لے آؤٹ فیلڈ کو تبدیل کرنا چاہتی ہے، تو انہیں مشترکہ گیٹ وے ٹیم کا نیا ورژن تعینات کرنے کا انتظار کرنا ہوگا، جس سے ترقی کے چکروں میں کمی آئے گی۔
• مختلف سیکیورٹی ضروریات: ایک ویب براؤزر کو کراس سائٹ اسکرپٹنگ (XSS) کو روکنے کے لیے کوکی پر مبنی سیشنز کی ضرورت پڑسکتی ہے، جبکہ ایک موبائل ایپ ٹوکن پر مبنی OAuth ہیڈر کو ترجیح دیتی ہے۔ ایک ہی سرور میں دونوں کو سنبھالنا پیچیدہ، گندا کوڈ بناتا ہے۔

حل: BFF پیٹرن

تمام آلات کے لیے ایک بڑا گیٹ وے بنانے کے بجائے، BFF پیٹرن ہر فرنٹ اینڈ ایپلیکیشن کے لیے ایک وقف شدہ بیک اینڈ سرور بنانے کی وکالت کرتا ہے۔

آپ کے پاس ہوگا: *** ویب BFF**: ڈیسک ٹاپ براؤزر سے درخواستوں کو ہینڈل کرتا ہے۔ یہ مکمل پروفائلز، پروڈکٹ کیٹلاگ، اور چیک آؤٹ کی تفصیلی معلومات کو جمع کرتا ہے۔

• موبائل 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. ویب BFF (مکمل تفصیلی پے لوڈ واپس کرتا ہے)

ویب 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 (کم سے کم واپسی، مجموعی پے لوڈ)

موبائل 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'));

پے لوڈ سائز کا موازنہ

• ویب بی ایف ایف رسپانس سائز: نیسٹڈ کنفیگریشن، ترجیحات، مکمل آرڈر کی فہرست، ٹیکس، آئٹمز وغیرہ پر مشتمل ہے۔ (تقریباً 400 بائٹس)۔
• موبائل BFF رسپانس سائز: صرف 6 کلیدی قدر کے جوڑے پر مشتمل ہے جو ننگی ضروری چیزوں کی نمائندگی کرتا ہے۔ (تقریباً 120 بائٹس—70% کمی نیٹ ورک کے سائز میں!)

BFF پیٹرن کے فائدے اور نقصانات

انتہائی مؤثر ہونے کے باوجود، BFF پیٹرن میں تجارتی تعلقات ہیں:

نتیجہ

بیک اینڈ فار فرنٹ اینڈ (BFF) پیٹرن ان سسٹمز کے لیے ایک طاقتور فن تعمیر ہے جو متعدد کلائنٹ کی اقسام، جیسے ویب، موبائل، اور IoT ڈیوائسز کی خدمت کرتا ہے۔ ہر مخصوص فرنٹ اینڈ کے لیے موزوں گیٹ وے بنا کر، آپ کلائنٹ کی ترقی کو دوگنا کرتے ہیں، پے لوڈ کا سائز کم کرتے ہیں، اور تیز تر، زیادہ جوابدہ صارف کا تجربہ فراہم کرتے ہیں۔

اگر آپ کے سسٹم میں صرف ایک ویب ایپلیکیشن ہے، تو ایک مشترکہ API گیٹ وے کافی ہے۔ لیکن جس لمحے آپ اپنی ویب ایپلیکیشن کے ساتھ موبائل ایپس یا خصوصی ڈیوائس کے تجربات بنانا شروع کرتے ہیں، BFF کو لاگو کرنا آپ کے فرنٹ اینڈ اور بیک اینڈ آرکیٹیکچرز کو صاف، بہتر اور خود مختار رکھنے کا بہترین طریقہ ہے۔

غزنکس بلاگ پر مزید سافٹ ویئر ڈویلپمنٹ اور بیک اینڈ انجینئرنگ کی بصیرتیں دریافت کریں →