২৪ মার্চ, ২০২৫·7 মিনিট পড়তে

API গেটওয়ে বনাম BFF: ওয়েব ও মোবাইল ক্লায়েন্টদের জন্য ট্রেডঅফস

API গেটওয়ে বনাম BFF: জানুন কিভাবে প্রতিটি প্যাটার্ন ভার্সনিং, পারফরম্যান্স, এবং ওয়েব ও মোবাইল অ্যাপের জন্য পাবলিক ও ইন্টারনাল এন্ডপয়েন্ট আলাদা করার উপায়কে প্রভাবিত করে।

সমস্যাটি: একটাই ব্যাকএন্ড, বহু ক্লায়েন্ট, পরিবর্তনশীল চাহিদা

শুরুতে পরিস্থিতি সাধারণ থাকে: একটাই ব্যাকএন্ড কিছু এন্ডপয়েন্ট উন্মোচন করে, এবং ওয়েব অ্যাপ ও মোবাইল অ্যাপ উভয়ই সেগুলোকে কল করে। এটি কার্যকর মনে হয় কারণ ফিচার যোগ করা, বাগ ফিক্স করা এবং নিয়ম প্রয়োগ করার জন্য একটাই জায়গা থাকে।

কিন্তু বাস্তবতা আলাদা। ওয়েব UI প্রায়ই ঘন স্ক্রিন, ফিল্টার, এক্সপোর্ট এবং অ্যাডমিন অ্যাকশন চায়। মোবাইল সাধারণত কম ফিল্ড, দ্রুত স্ক্রিন, অফলাইন-বন্ধুত্বপূর্ণ ফ্লো এবং ব্যাটারি ও ডেটা ব্যবহারে সতর্কতা চায়। এমনকি যখন ফিচার “একই” মনে হয়, প্রতিটি ক্লায়েন্টের জন্য সর্বোত্তম API আকার খুব কমই একরকম থাকে।

সময় ধরে এন্ডপয়েন্ট ড্রিফট করে। ওয়েব টিম একটি টেবিল ভিউয়ের জন্য অতিরিক্ত ফিল্ড যোগ করে। মোবাইল ভারী পে-লোড বাদ দিতে এবং একাধিক কলকে একটিতে মিলাতে চায়। কেউ “শুধু iOS-র জন্য” একটি প্যারামিটার যোগ করে। আরেকজন ইন্টারনাল অ্যাডমিন এন্ডপয়েন্টকে পাবলিক অ্যাপে ব্যবহার করে কারণ সেটা “ইতিমধ্যেই ছিল”। যা শুরুতে এক ক্লিন API ছিল তা হঠাৎ সমঝোতার সমাহার হয়ে যায়।

ঝুঁকিগুলো দ্রুত দেখা দেয়:

যখন এক ক্লায়েন্ট দ্রুত শিপ করে অন্য ক্লায়েন্ট ভাঙা পরিবর্তনের সম্মুখীন হয়
বড় পে-লোড বা অনেক রাউন্ডট্রিপের কারণে অ্যাপ ধীরগতির হয়ে ওঠে
প্রতিটি এন্ডপয়েন্ট সব ক্লায়েন্টকে সার্ভ করার চেষ্টা করায় ব্যাকএন্ড কোড জটিল হয়
ইন্টারনাল ফিল্ড বা অ্যাকশন পাবলিক API-তে লিক হয়ে যায়
ছোট পরিবর্তনও পুরনো ক্লায়েন্টদের জন্য কষ্টকর ভার্সনিং সৃষ্টি করে

ইইটি API গেটওয়ে বনাম BFF আলাপচারিতার মুল টানাপোড়েন। আপনি স্থিতিশীল পাবলিক API চান যাতে মোবাইল ও ওয়েব নির্ভর করতে পারে, এবং একই সময়ে প্রতিটি ক্লায়েন্টকে আলাদা গতিতে বিকশিত হওয়ার জায়গা দিতে চান।

API গেটওয়ে ও BFF: কি তারা এবং কি নয়

API গেটওয়ে হলো আপনার API-গুলোর একটি সামনে দরজা। ক্লায়েন্ট গেটওয়েকে কল করে, এবং এটি অনুরোধগুলো সঠিক ব্যাকএন্ড সার্ভিসে রাউট করে। এটি সাধারণত authentication চেক, rate limits, request logging এবং বেসিক রিকোয়েস্ট শেপিংয়ের মতো শেয়ার্ড দায়িত্বগুলো করে, যেগুলো আপনি প্রত্যেক জায়গায় পুনরাবৃত্তি করতে চান না।

Backend-for-frontend (BFF) হলো একটি ছোট ব্যাকএন্ড যা একটি নির্দিষ্ট ক্লায়েন্ট বা ক্লায়েন্ট গ্রুপের জন্য তৈরি, যেমন “web” বা “mobile”। ক্লায়েন্ট তার BFF-কে কল করে, আর BFF underlying সার্ভিসগুলোকে কল করে। মূল ভাবনা হল ফোকাস: BFF ক্লায়েন্টের ভাষায় কথা বলার অনুমতি পায় (স্ক্রিন, ফ্লো, এবং পে-লোড), যদিও মূল সার্ভিসগুলো বেশি generic থেকেই যায়।

এই প্যাটার্নগুলো কি নয়: এগুলো ভালো ডোমেইন সার্ভিস বা পরিষ্কার ডেটা মডেলের বিকল্প নয়। আপনার কোর সার্ভিস, ডেটাবেস এবং বিজনেস রুলসেরাই সত্যের উৎস থাকা উচিত। একটি গেটওয়ে বা BFF ধীরে ধীরে আপনার বাস্তব ব্যাকএন্ডে পরিণত হওয়া উচিত নয়।

সোজা করে আলাদা করার উপায়:

Gateway: এক এন্ট্রি পয়েন্ট, শেয়ার্ড দায়িত্ব, রাউটিং ও সুরক্ষা
BFF: ক্লায়েন্ট-নির্দিষ্ট API যা ক্লায়েন্টের কাজ কমায় এবং ইন্টারনাল জটিলতা লুকায়

আপনি এগুলো মিলিয়েও ব্যবহার করতে পারেন। একটি সাধারণ সেটআপ হলো পাবলিক এজ হিসেবে একটি গেটওয়ে, এবং তার পেছনে ওয়েব ও মোবাইলের জন্য আলাদা BFF। গেটওয়ে বাইরের সিকিউরিটি ও ট্রাফিক নিয়ম সামলে, প্রতিটি BFF ক্লায়েন্টের জন্য এন্ডপয়েন্ট ও রেসপন্স শেপ করে।

প্রতিটি প্যাটার্নে অনুরোধ পথ কেমন পরিবর্তিত হয়

API গেটওয়ে ও BFF-এর মধ্যে সবচেয়ে বড় পার্থক্য হলো আপনি কোথায় “ফ্রন্ট ডোর” লজিক রাখেন: রাউটিং, authentication চেক, এবং রেসপন্স শেপিং।

API গেটওয়ের ক্ষেত্রে ক্লায়েন্ট সাধারণত একটি শেয়ার্ড এন্ট্রি পয়েন্টে কথা বলে। গেটওয়ে অনুরোধগুলো ইন্টারনাল সার্ভিসে ফরওয়ার্ড করে, প্রায়ই টোকেন ভ্যালিডেশন, রেট লিমিট, এবং পাথে ভিত্তিক রাউটিংয়ের মতো বেসিক কাজ করে।

BFF-এ প্রতিটি ক্লায়েন্ট টাইপ (web, iOS, Android) তার জন্য তৈরি ব্যাকএন্ডকে কল করে। সেই BFF পরে ইন্টারনাল সার্ভিসগুলোকে কল করে এবং সেই ক্লায়েন্টের স্ক্রিন ও সীমাবদ্ধতার জন্য টেইলার্ড রেসপন্স ফিরিয়ে দেয়।

সহজভাবে অনুরোধ পথ কল্পনা করা যায়:

API gateway path: Client -> Gateway -> Service(s) -> Response
BFF path: Client -> BFF (web or mobile) -> Service(s) -> Response

ওনারশিপও প্রায়ই বদলে যায়। গেটওয়ে সাধারণত একটি প্ল্যাটফর্ম বা ইনফ্রাস্ট্রাকচার টিমের অধীনে থাকে কারণ এটি প্রতিটি টিম ও সার্ভিসকে প্রভাবিত করে। BFF সাধারণত একটি ফিচার টিমের অধীনে থাকে কারণ এটি UI এবং তার রিলিজ সাইকেলের সঙ্গে চলে।

Authentication সাধারণত এভাবে প্রবাহিত হয়: ক্লায়েন্ট টোকেন পাঠায়, এজ লেয়ার (গেটওয়ে বা BFF) এটি যাচাই করে অথবা একটি auth সার্ভিসকে প্রেরণ করে, এবং তারপর downstream সার্ভিসগুলোতে identity বিবরণ (user id, roles) ফরওয়ার্ড করে। পার্থক্য হলো কোথায় ক্লায়েন্ট-নির্দিষ্ট নিয়ম প্রয়োগ করা হয়। গেটওয়ে হলে নীতিগুলো সাধারণত জেনেরিক ও ক্লায়েন্টগুলোর মধ্যে সঙ্গতিপূর্ণ থাকে। BFF-এ আপনি ক্লায়েন্ট-নির্দিষ্ট শেপিং যোগ করতে পারেন, যেমন মোবাইলের জন্য ছোট পে-লোড বা ধীর নেটওয়ার্কে একাধিক সার্ভিস কলকে এক রেসপন্সে মিশিয়ে দেয়া।

এই শেপিং স্টেপেই BFF উজ্জ্বল হয়, কিন্তু এর মানে হচ্ছে deploy ও কনসিস্টেন্সি বজায় রাখার জন্য আরও ঘূর্ণমান অংশ আছে।

পাবলিক বনাম ইন্টারনাল এন্ডপয়েন্ট নিরাপদে আলাদা করা

পাবলিক এন্ডপয়েন্ট হলো কোনো API রাউট যা আপনার ওয়েব অ্যাপ, মোবাইল অ্যাপ, পার্টনার বা তৃতীয় পক্ষ পৌঁছাতে পারে। এটি ডিফল্টভাবে শত্রুসম্মত ভাবুন, কারণ আপনি নেটওয়ার্ক বা ক্লায়েন্ট কোড নিয়ন্ত্রণ করতে পারবেন না।

ইন্টারনাল এন্ডপয়েন্টটি সার্ভিস-টু-সার্ভিস ট্রাফিকের জন্য, সিস্টেমের ভিতরে। এটি দ্রুত পরিবর্তন হতে পারে, আরও প্রসঙ্গ ধরে নিতে পারে, এবং সমৃদ্ধ ডেটা উন্মোচন করতে পারে, কিন্তু কখনই সরাসরি পাবলিক ইন্টারনেট থেকে পৌঁছানো উচিত নয়।

API গেটওয়ের সাথে বিভাজন প্রায়শই ভৌত ও সহজে বোঝার যোগ্য হয়: শুধুমাত্র গেটওয়ে প্রকাশিত থাকে, এবং এটি নির্ণয় করে কোন বাইরের রুটগুলো থাকবে। এর ফলে আপনি ইন্টারনাল সার্ভিস API-গুলো প্রকাশ করেই পরিবর্তন করতে পারেন, আর গেটওয়ে একটি ছোট, নিরাপদ সারফেস বজায় রাখে।

Backend-for-frontend প্যাটার্নে বিভাজনটি বেশি প্রোডাক্ট-বাউন্ডারি সম্পর্কিত। প্রতিটি ক্লায়েন্ট (web, iOS, Android) কেবল তার BFF-কে বলবে, আর BFF ইন্টারনাল সার্ভিসগুলোকে কল করবে। এতে আপনি ইন্টারনাল জটিলতা লুকাতে পারবেন: BFF তিনটি সার্ভিস কল করে ফলাফল মিলিয়ে একটি সহজ রেসপন্স দিতে পারে যেটা ক্লায়েন্টের প্রয়োজন অনুযায়ী।

এই বিভাজন তখনই নিরাপদ যখন আপনি বাস্তব নিয়ন্ত্রণ যোগ করেন:

স্পেসিফিক authorization: প্রতিটি রুটের জন্য রোল ও স্কোপ, কেবল একটি "logged in" সুইচ নয়
পাবলিক রুটের জন্য ইউজার, টোকেন, এবং IP অনুযায়ী rate limits
পে-লোড ফিল্টারিং: ক্লায়েন্ট কেবল যা প্রয়োজন তা ফেরত দিন, ইন্টারনাল ID, ডিবাগ ইনফো ও অ্যাডমিন-অনলি ফিল্ড সরিয়ে দিন
স্পষ্ট allowlists: কোন এন্ডপয়েন্ট পাবলিক, কোনটি ইন্টারনাল-ওনলি

উদাহরণ: মোবাইল অ্যাপের "My Orders" স্ক্রিন দরকার। BFF /orders এক্সপোজ করতে পারে যেখানে কেবল অর্ডারের স্ট্যাটাস ও টোটাল আছে, আর ইন্টারনাল অর্ডার সার্ভিস বিস্তারিত কস্ট ব্রেকডাউন ও ফ্রড ফ্ল্যাগ প্রাইভেট রাখে।

ভার্সনিং: কি সহজ হয় আর কি কঠিন হয়

Ship the web portal quicker

Create dense admin screens and portals while keeping API contracts predictable.

Build Web App

ভার্সনিং-এর ব্যথা সাধারণত তখন দেখা দেয় যখন ওয়েব ও মোবাইল ভিন্ন গতিতে চলে। ওয়েব টিম ঘণ্টার মধ্যে শিপ ও রোলব্যাক করতে পারে। মোবাইল অ্যাপের ক্ষেত্রে অ্যাপ স্টোর রিভিউ ও ইউজাররা আপডেট না করায় দিন বা সপ্তাহ লাগতে পারে। সেই ফাঁকেই API গেটওয়ে বনাম BFF সিদ্ধান্তটা ব্যবহারিক হয়ে ওঠে।

API গেটওয়ের সাথে আপনি এক ফ্রন্ট ডোরে ভার্সনিং রাখতে পারেন (উদাহরণ /v1/..., /v2/...)। এটি ব্যাখ্যা করা সহজ ও রাউট করা সহজ। কিন্তু অসুবিধা হলো অনেক ক্লায়েন্ট ও পার্টনার ইন্টিগ্রেশন পুরনো ভার্সনে আটকে গেলে গেটওয়ে একটি ভার্সন মিউজিয়ামে পরিণত হতে পারে। আপনাকে পুরনো ডেটা শেপ দীর্ঘ সময় সাপোর্ট করতে হবে।

BFF-এ ভার্সনিং প্রায়ই "প্রতি ক্লায়েন্ট" হয়। মোবাইল BFF পুরনো কন্ট্রাক্টে থাকতে পারে যখন ওয়েব BFF দ্রুত এগোয়, যদিও উভয় একই ইন্টারনাল সার্ভিসে কথা বলে। এতে সাধারণত পাবলিক ভার্সন দীর্ঘ সময় ধরে রাখতে চাপ কমে। ট্রেডঅফ হলো বেশি মুভিং পার্ট: এখন আপনাকে একাধিক ভার্সন সিদ্ধান্ত ম্যানেজ ও ডিপ্লয় করতে হবে।

সার্ভিসের ভিতরে ভার্সনিংও কাজ করে, কিন্তু এটি ক্লায়েন্ট-চালিত পরিবর্তনগুলো আপনার সিস্টেমের গভীরে ধাক্কা দেয়। এছাড়াও ইন্টারনাল কোড কঠিন হয়ে পড়ে কারণ সার্ভিস লজিকে ক্লায়েন্ট ভার্সনের ওপর শাখা পড়তে শুরু করে।

নন-ব্রেকিং পরিবর্তনগুলো আপনার সর্বশ্রেষ্ঠ বন্ধু: অপশনাল ফিল্ড যোগ করা, নতুন এন্ডপয়েন্ট যোগ করা, অথবা অতিরিক্ত ইনপুট ফিল্ড গ্রহণ করা। ব্রেকিং পরিবর্তনে আসে: একটি ফিল্ডের নাম বদলানো, টাইপ বদলানো (string থেকে number), বা একটি এন্ডপয়েন্ট সরানো।

ডিপ্রেকশন সবচেয়ে ভালো কাজ করে যখন তা পরিকল্পিত হয়:

একটি স্পষ্ট sunset তারিখ সেট করুন এবং আগেভাগে জানিয়ে দিন
পুরনো ভার্সনের ব্যবহার ট্র্যাক করুন (লগ, মেট্রিক্স) এবং স্ট্র্যাগলার দেখুন
ক্লায়েন্ট আপডেটগুলো আগে রোল আউট করুন (বিশেষ করে মোবাইল), তারপর পুরনো পাথ সরান
যখন পুরনো ভার্সন ব্লক করা হয়, স্পষ্ট একটি এরর মেসেজ ফেরত দিন

পারফরম্যান্স: ল্যাটেন্সি, পে-লোড সাইজ, এবং কল সংখ্যা

API গেটওয়ে বনাম BFF সেটআপে পারফরম্যান্স মূলত একটি ট্রেড: আপনার সিস্টেমের ভিতরে একটি অতিরিক্ত হপ বনাম ক্লায়েন্টের কাছ থেকে কম হপ ও দ্রুততা। দ্রুততম অপশন প্রায়ই সেই অপশন যা ক্লায়েন্টের ধীর, অনিশ্চিত নেটওয়ার্ক টাইম কমায়, যদিও এটি একটি ছোট সার্ভার-সাইড ধাপ যোগ করে।

মোবাইল ক্লায়েন্ট যখন অনেক কল করে, তখন BFF প্রায়ই জিতে যায়। ওয়েব ও মোবাইল যদি পাঁচটি এন্ডপয়েন্ট কল করে এবং ডিভাইসে ফলাফল জোড়া দেয়, BFF সার্ভার-সাইডে প্রয়োজনীয় জিনিসগুলো নিয়ে এসে এক রেসপন্সে ফেরত দিতে পারে। এটি সাধারণত মোবাইলের মোট ল্যাটেন্সি কমায় কারণ সেলুলার নেটওয়ার্ক প্রতিটি অনুরোধে ডিলে যোগ করে।

গেটওয়ে বা BFF থেকে সাধারণ পারফরম্যান্স উপকারগুলো:

Aggregation: একাধিক সার্ভিস থেকে ডেটা এক রেসপন্সে মিলানো
স্মার্ট ক্যাশিং: এজ বা BFF-এ ক্যাশ করা পড়ুন-ভারী স্ক্রিনের জন্য
ছোট পে-লোড: কেবল স্ক্রিনে যা লাগে তাই ফেরত দিন
কম রাউন্ড ট্রিপ: চ্যাটি ক্লায়েন্ট আচরণ কমানো
কনসিসটেন্ট কমপ্রেশন ও টাইমআউট: এক জায়গায় ডিফল্টগুলি প্রয়োগ করা

কিন্তু প্যাটার্নটাও ক্ষতি করতে পারে। প্রতিটি অতিরিক্ত লেয়ার CPU কাজ বাড়ায় এবং অপেক্ষা করার আরও জায়গা তৈরি করে। যদি আপনি ওয়েব ও মোবাইলের জন্য একই aggregation লজিক ডুপ্লিকেট করেন, আপনি কাজ দুগুন করে ফেলতে পারেন এবং inconsistent আচরণ তৈরি করতে পারেন। ওভার-ফেচিং আরেকটি সাধারণ ক্ষতি: একটি generic এন্ডপয়েন্ট যা প্রতিটি স্ক্রিনকে সন্তুষ্ট করার চেষ্টা করে বড় পে-লোড ফেরত দেয় যা সময় ও ব্যান্ডউইথ নষ্ট করে।

মোবাইল বাস্তবতা এই ট্রেডঅফগুলোকে আরও তীক্ষ্ণ করে। ফ্ল্যাকি নেটওয়ার্ক মানে রিট্রাই ও টাইমআউট স্বাভাবিক, এবং প্রতিটি অতিরিক্ত কল ব্যাটারি খরচ করে। কোল্ড স্টার্টও গুরুত্বপূর্ণ: যদি অ্যাপটি প্রথম স্ক্রিনের জন্য কয়েকটি রিকোয়েস্ট আগে লাগে, ইউজার সেটি অনুভব করে।

একটি ব্যবহারিক নিয়ম: প্রথমে কম ক্লায়েন্ট রিকোয়েস্টের জন্য অপ্টিমাইজ করুন, তারপর অতিরিক্ত হপ অপ্টিমাইজ করুন।

একটি দ্রুত বিচারবাণী

যদি একটি স্ক্রিনে 2-3 এর বেশি সিকোয়েন্সিয়াল কল লাগে, aggregation বিবেচনা করুন। যদি রেসপন্সগুলো বড় এবং বেশিরভাগ ব্যবহার হয় না, তাহলে এন্ডপয়েন্ট ভাগ করা বা ক্লায়েন্ট-অনুযায়ী BFF ব্যবহার করা বিবেচনা করুন।

অপারেশন: ডিপ্লয়মেন্ট, মনিটরিং, এবং স্কেলিং

Optimize mobile payloads

Deliver smaller responses and faster flows for iOS and Android clients.

Build Mobile App

API গেটওয়ে বনাম BFF নিয়ে বড় অপারেশনাল প্রশ্ন হলো আপনি কতটা মুভিং পার্ট চালাতে ও সাপোর্ট করতে চান। গেটওয়ে প্রায়ই অনেক টিম ও ক্লায়েন্টের জন্য শেয়ার্ড ইনফ্রা হয়ে যায়। BFF সাধারণত ছোট সার্ভিস হলেও, আপনি প্রতিটি ক্লায়েন্টের জন্য একটি করে BFF পেতে পারেন (web, iOS, Android, partner), যা রিলিজ ও অন-কল লোড বাড়িয়ে দেয়।

টেস্টিং ও রিলিজে, যখন আপনি প্রধানত রাউটিং, auth, এবং rate limits দরকার, গেটওয়ে বেশি সেফ হতে পারে। পরিবর্তনগুলি কেন্দ্রীভূত হওয়ায় একটি ভুল সবার ওপর প্রভাব ফেলতে পারে। BFF-গুলো ব্লাস্ট রেডিয়াস কমায় কারণ একটি ওয়েব-নির্দিষ্ট পরিবর্তন ওয়েব BFF-এ শিপ হয়, মোবাইল BFF-এ নয়। ট্রেডঅফ হলো আরও পাইপলাইন বজায় রাখা এবং বেশি ভার্সন চলমান থাকা।

অবজার্ভেবিলিটির জন্য, আপনাকে একজন ইউজার রিকোয়েস্টকে লেয়ার জুড়ে দেখতে হবে, বিশেষ করে যখন একটি মোবাইল কল কয়েকটি ব্যাকেন্ড কল ট্রিগার করে।

একটি correlation ID ব্যবহার করুন এবং এটি গেটওয়ে, BFF, এবং ব্যাকেন্ড লগে পাঠান
ট্রেস ক্যাপচার করুন যাতে আপনি দেখতে পারেন সময় কোথায় যাচ্ছে (গেটওয়ে, BFF, ডাউনস্ট্রীম সার্ভিস)
স্ট্রাকচার্ড লগ রাখুন (ক্লায়েন্ট, এন্ডপয়েন্ট, স্ট্যাটাস কোড, ল্যাটেন্সি, পে-লোড সাইজ)
প্রতিটি এন্ডপয়েন্টের জন্য কয়েকটি কী মেট্রিক ট্র্যাক করুন: error rate, p95 latency, throughput

স্কেলিংও ভিন্নভাবে দেখায়। গেটওয়ে একটি শেয়ার্ড চোক পয়েন্ট: এটি স্পাইক ও হট এন্ডপয়েন্ট হ্যান্ডেল করতে হবে। BFF-গুলো আপনাকে ক্লায়েন্ট অনুযায়ী স্কেল করতে দেয়, যা তখন সাহায্য করে যখন ব্যবসার সময় ওয়েব ট্রাফিক ঝাঁকুনি খায় কিন্তু মোবাইল স্থির থাকে।

ইনসিডেন্টে, ফেলিওরগুলো প্যাটার্ন অনুযায়ী "সরে" যেতে পারে। গেটওয়ের সাথে সমস্যা প্রায়ই বিস্তৃত 5xx বা auth ফেলিয়ারে দেখা যায়। BFF-গুলোর সাথে সমস্যা হয় নির্দিষ্ট এক ক্লায়েন্টের ফিচারে। রুনবুকগুলো স্পষ্ট রাখুন কোথায় প্রথমে খুঁজবে, এবং fallback আচরণ সহজ রাখুন (উদাহরণ: টাইমআউটের বদলে একটি রিডিউসড রেসপন্স ফেরত দিন)।

কীভাবে নির্বাচন করবেন: সহজ ধাপে ধাপে সিদ্ধান্ত প্রক্রিয়া

Extend APIs without breaking clients

Add payments, messaging, and integrations when you need them, not upfront.

Create Modules

API গেটওয়ে বনাম BFF নির্বাচন তত্ত্বের চেয়ে বেশি নির্ভর করে আপনার ক্লায়েন্টদের দৈনন্দিন চাহিদার উপর।

ব্যবহারিক সিদ্ধান্ত প্রবাহ

সার্ভার নয়, ক্লায়েন্ট দিয়ে শুরু করুন। আপনি যে প্রতিটি ক্লায়েন্ট সমর্থন করেন (ওয়েব অ্যাপ, iOS, Android, পার্টনার API, ইন্টারনাল অ্যাডমিন) সেগুলো লিখে নিন এবং প্রতিটি মূল স্ক্রিন কী চায় তা তালিকা করুন। যদি একই "Customer details" ভিউ বিভিন্ন ক্লায়েন্টে বিভিন্ন ফিল্ড ও বিভিন্ন কল প্যাটার্ন চায়, সেটি ক্লায়েন্ট-নির্দিষ্ট শেপিংয়ের শক্ত সংকেত।
বর্তমানে যা আছে তা ম্যাপ করুন। আপনার বর্তমান এন্ডপয়েন্টগুলো নিয়ে নিন এবং চিহ্নিত করুন কোনগুলো শেয়ার্ড (কোর ডোমেইন অপারেশন যেমন orders, payments, users) এবং কোনগুলো presentation-shaped (একটি ড্যাশবোর্ড সারাংশ, একটি combined "home screen" পে-লোড)। শেয়ার্ড অংশগুলো কোর ব্যাকএন্ডে থাকা উচিত। presentation-shaped অংশগুলো সাধারণত BFF-এ ভালো বসে।
সিদ্ধান্ত নিন কোথায় শেইপিং ও নিয়ম থাকা উচিত। যদি মূলত রাউটিং, auth, rate limits, caching, এবং পাবলিক বনাম ইন্টারনাল এন্ডপয়েন্টের নিরাপদ প্রকাশ দরকার হয়, গেটওয়ে প্রাকৃতিক স্থান। যদি বাস্তবে composition দরকার (একাধিক সার্ভিস কল করা, ছয় কলকে একটিতে পরিণত করা, বিভিন্ন অ্যাপে ভিন্ন পে-লোড), সেই লজিক BFF কোডে রাখুন যাতে তা টেস্টেবল ও পড়তে সহজ থাকে।
একটি ভার্সনিং ও ডিপ্রেকশন নিয়ম বেছে নিন যা আপনি বাস্তবে অনুসরণ করবেন। উদাহরণ: "কোন বিপর্যয়কর পরিবর্তন নতুন ভার্সন ছাড়া নয়, এবং প্রতিটি ডিপ্রিকেটেড ফিল্ড ৯০ দিন ধরে থাকে।" গেটওয়ে-ওনলি অ্যাপ্রোচে আপনি পাবলিক সারফেস ভার্সনিং করে অনুবাদ করতে পারেন। BFF-গুলোর সাথে, আপনি প্রায়শই কোর API গুলোকে স্থিতিশীল রেখে কেবল BFF এন্ডপয়েন্টগুলো ক্লায়েন্ট অনুযায়ী ভার্সন করতে পারেন।
রোলআউট পরিকল্পনা করুন এবং মাপুন। কিছু পাল্টানোর আগে বেসলাইন মেট্রিকস সংগ্রহ করুন: p95 latency, স্ক্রিনে কল সংখ্যা, পে-লোড সাইজ, এবং error rate। প্রথমে ছোট শতাংশে রোল আউট করুন, আগে ও পরে তুলনা করুন, তারপর বাড়ান।

একটি সহজ উদাহরণ: যদি আপনার মোবাইল অ্যাপ মাসিক রিলিজ করে কিন্তু ওয়েব পোর্টাল দৈনিক শিপ করে, একটি ছোট মোবাইল BFF অ্যাপের কাছে ব্যাকএন্ড পরিবর্তন থেকে অ্যাপকে রক্ষা করতে পারে যখন ওয়েব ক্লায়েন্ট দ্রুত চলে।

উদাহরণ: ভিন্ন রিলিজ স্পিডের ওয়েব পোর্টাল + মোবাইল অ্যাপ

ধারণা করুন একটি কোম্পানি যার কস্টমার পোর্টাল ওয়েবে এবং একটি ফিল্ড অ্যাপ মোবাইল-এ আছে। উভয়ই একই কোর ডেটা চায়: customers, jobs, invoices, এবং messages। পোর্টাল বেশি ঘন ঘন পরিবর্তিত হয়। মোবাইল অ্যাপ ধীরে আপডেট হয় কারণ অ্যাপ স্টোর রিভিউ লাগে এবং দুর্বল সিগন্যালেও কাজ করতে হবে।

দ্রুত সমস্যাগুলো দেখা দেয়। মোবাইল ব্যবহারকারীরা সংক্ষিপ্ত রেসপন্স, কম কল, এবং সিঙ্ক ফ্লো চায় (উদাহরণ: আজকের জবগুলো একবার ডাউনলোড করে পরে পরিবর্তনগুলো সিঙ্ক করা)। ওয়েব পোর্টাল বেশি কল এবং সমৃদ্ধ স্ক্রিন ম্যানেজ করতে পারে কারণ এটি সবসময় অনলাইন এবং সহজে আপডেটযোগ্য।

অপশন A: স্থিতিশীল সার্ভিসগুলির সামনে একটি API গেটওয়ে

গেটওয়ে-ফার্স্ট পছন্দ আপনার ব্যাকএন্ড সার্ভিসগুলোকে মূলত অপরিবর্তিত রাখে। গেটওয়ে authentication, routing, এবং হালকা টুইক যেমন হেডার, rate limits এবং সহজ ফিল্ড ম্যাপিং সামলায়।

ভার্সনিং প্রধানত সার্ভিস API স্তরে থাকে। এটি ভালো: কম মুভিং পার্ট। কিন্তু এতে মোবাইল-নির্দিষ্ট পরিবর্তনগুলো প্রায়ই বড় ভার্সনে বাঁধা পড়ার দিকে ঠেলে দেয় যেমন /v2 কারণ underlying এন্ডপয়েন্টগুলো শেয়ার্ড।

এন্ডপয়েন্ট এক্সপোজার স্পষ্ট হয় যদি আপনি গেটওয়েকে একমাত্র পাবলিক ডোর ধরে নেন। ইন্টারনাল এন্ডপয়েন্টগুলো পেছনে থাকলে, গেটওয়ে কি প্রকাশ করবে তা কড়া নিয়ন্ত্রণ করতে হবে।

অপশন B: মোবাইল-ভাষায় কথা বলা একটি মোবাইল BFF

মোবাইল BFF-এ মোবাইল অ্যাপ সেই এন্ডপয়েন্টগুলোকে কল করে যা মোবাইল স্ক্রীন ও সিঙ্ক ফ্লো জন্য ডিজাইন করা। BFF ডেটা aggregate করতে পারে (job details + customer + last message), ফিল্ড ট্রিম করতে পারে, এবং একটি পে-লোড ফেরত দিতে পারে যা অ্যাপের চাহিদার সাথে মিলে।

কি পরিবর্তন হয়:

ভার্সনিং প্রতি ক্লায়েন্ট হিসেবে সহজ হয়: আপনি মোবাইল BFF ভার্সন করতে পারবেন ওয়েব পোর্টালকে বাধ্য না করে
পারফরম্যান্স প্রায়শই মোবাইলের জন্য উন্নত হয়: কম রাউন্ড ট্রিপ ও ছোট রেসপন্স
পাবলিক বনাম ইন্টারনাল বিভাজন আরও ধারালো হয়: BFF পাবলিক, কিন্তু এটি যে ইন্টারনাল সার্ভিসগুলোকে কল করে সেগুলো কখনই প্রকাশ করা লাগবে না

সাধারণ ভুল ও ফাঁদ এড়ানো

Test a mobile BFF fast

Prototype a mobile-friendly aggregation layer that cuts round trips and trims payloads.

Build a BFF

API গেটওয়ে বনাম BFF আলাপচারিতায় সবচেয়ে বড় ফাঁদ হলো গেটওয়েকে একটি ছোট ব্যাকএন্ডে পরিণত করা। গেটওয়ে রাউটিং, auth, rate limits, এবং সহজ অনুরোধ শেপিংয়ে ভালো। যখন আপনি সেখানে বিজনেস রুলস ভরে দেন, তখন আপনি লুকানো লজিক পান যা টেস্ট করা কঠিন, ডিবাগ করা কঠিন, এবং কনফিগ চেঞ্জে ভাঙা সহজ।

BFF-গুলো উল্টো দিকে ভুল করতে পারে: টিমরা প্রতিটি স্ক্রিন বা ফিচারের জন্য একটি BFF তৈরি করে, এবং মেইনটেনেন্স বিস্ফোরিত হয়। একটি BFF সাধারণত একটি ক্লায়েন্ট টাইপ (web, iOS, Android) বা স্পষ্ট প্রোডাক্ট এরিয়ারকে ম্যাপ করা উচিত, প্রতিটি UI ভিউ নয়। অন্যথায় একই নিয়ম দশটি জায়গায় ডুপ্লিকেট হবে, এবং ভার্সনিং পূর্ণকালীন কাজ হয়ে যাবে।

ভার্সনিং ভুলগুলো প্রায়ই এক্সট্রিম থেকে আসে। আপনি যদি প্রথম দিনেই সবকিছু ভার্সন করেন, আপনি খুব দ্রুত API ফ্রোজেন করে দেবেন এবং পুরনো ভ্যারিয়েন্ট চিরস্থায়ী হয়ে উঠবে। যদি আপনি কখনই ভার্সন না করেন, আপনি শেষমেশ অনিচ্ছাকৃতভাবে ব্রেকিং পরিবর্তন পাঠাবেন। একটি সহজ নিয়ম প্রায়শই ভালো কাজ করে: ছোট অ্যাডিটিভ পরিবর্তনের জন্য ভার্সন করবেন না, কিন্তু কিছু সরালে বা অর্থ পরিবর্তন করলে ভার্সন করুন।

পাবলিক বনাম ইন্টারনাল এন্ডপয়েন্টে দলগুলো যেখানে আঘাত পায়। ইন্টারনাল সার্ভিসগুলোকে সরাসরি ইন্টারনেটে উন্মুক্ত করা (এমনকি "অস্থায়ীভাবে") প্রতিটি ইন্টারনাল পরিবর্তনকে সম্ভাব্য আউটেজ বা সিকিউরিটি ইস্যুতে পরিণত করে। একটি স্পষ্ট সীমাংশ রাখুন: কেবল গেটওয়ে বা BFF পবলিক হওয়া উচিত, এবং ইন্টারনাল সার্ভিসগুলো প্রাইভেট রাখুন।

পারফরম্যান্স সমস্যাগুলো সাধারণত আত্ম-সৃষ্ট: অতিরিক্ত বড় পে-লোড, অনেক রাউন্ডট্রিপ, এবং ল্যাটেন্সির জন্য বাজেট না থাকা। উদাহরণ: একটি মোবাইল অ্যাপ কেবল অর্ডার স্ট্যাটাস ও টোটাল প্রয়োজন, কিন্তু প্রতিটি অনুরোধে পুরো অর্ডার অবজেক্ট লাইন আইটেম ও অডিট ফিল্ড নিয়ে আসে, ফলে সেলুলারে প্রতিটি অনুরোধ ধীর।

চেতাবনির লক্ষণগুলো:

গেটওয়ে কনফিগে বিজনেস কনসেপ্ট যেমন "refund eligibility" বা "VIP rules" উল্লেখ আছে
BFF-গুলো ক্লায়েন্টগুলোর চেয়ে দ্রুত বাড়ছে
আপনি আপনার API ভার্সনিং কৌশল এক বাক্যে ব্যাখ্যা করতে পারবেন না
ইন্টারনাল সার্ভিস এন্ডপয়েন্টগুলো পাবলিক ইন্টারনেট থেকে পৌঁছানো যায়
রেসপন্সগুলো ক্রমশ বাড়ছে কারণ "হয়তো পরে দরকার হবে"

দ্রুত চেকলিস্ট এবং পরবর্তী ধাপ

আপনি যদি API গেটওয়ে বনাম BFF সিদ্ধান্তে আটকে থাকেন, প্রথমে সেই জিনিসগুলোর দিকে মনোযোগ দিন যা বাস্তবে প্রথমেই ভেঙে যাবে: রিলিজ, পে-লোড, এবং সিকিউরিটি বাউন্ডারি।

দ্রুত চেকলিস্ট

যদি আপনি একাধিক ক্ষেত্রে "না" উত্তর দেন, আপনার বর্তমান সেটআপ ক্লায়েন্টগুলো বাড়ার সাথে সাথে ক্ষতি করবে:

আপনি কি একটি ব্যাকএন্ড পরিবর্তন করতে পারেন একটি সপ্তাহে সব ক্লায়েন্টকে বাধ্য না করে?
পাবলিক এন্ডপয়েন্ট (ইন্টারনেট-সেফ) এবং ইন্টারনাল এন্ডপয়েন্ট (বিশ্বাসযোগ্য সিস্টেম) এর মধ্যে কি স্পষ্ট সীমা আছে?
ওয়েব ও মোবাইল কি কেবল তাদের প্রয়োজনীয় জিনিসই পাচ্ছে (বড় "কিচেন সিঙ্ক" রেসপন্স নয়)?
আপনি কি ছোট শতাংশে রোলআউট করতে পারেন এবং তাত্ক্ষণিকভাবে এরর, ল্যাটেন্সি, অস্বাভাবিক ট্রাফিক দেখতে পাবেন?
প্রতিটি এন্ডপয়েন্টের কন্ট্রাক্টের মালিক কে এবং ব্রেকিং পরিবর্তন কার অনুমোদন করে, আপনি কি জানেন?

পরবর্তী ধাপ

উত্তরগুলোকে একটি পরিকল্পনায় পরিণত করুন। লক্ষ্য নিখুঁত আর্কিটেকচার নয়, বরং শিপ করার সময় কম বিস্ময়।

আপনার API কন্ট্রাক্ট সাধারণ ভাষায় লিখুন (ইনপুট, আউটপুট, এরর কোড, কি পরিবর্তন করা যাবে)। একটি ওনারশিপ মডেল বেছে নিন: কে ক্লায়েন্ট চাহিদার জন্য (web/mobile) দায়ী এবং কে কোর ডোমেইন সার্ভিসের জন্য। সিদ্ধান্ত নিন কোথায় ভার্সনিং থাকবে (প্রতি ক্লায়েন্ট, বা কেন্দ্রীভূত) এবং একটি ডিপ্রেকশন নিয়ম নির্ধারণ করুন যেটা আপনি অনুসরণ করবেন।

বড় রিফ্যাক্টরের আগে বেসিক মনিটরিং যোগ করুন: রিকোয়েস্ট রেট, p95 ল্যাটেন্সি, এরর রেট, এবং টপ এন্ডপয়েন্টগুলো পে-লোড সাইজ অনুযায়ী। সবচেয়ে ঝুঁকিপূর্ণ ক্লায়েন্ট ফ্লোগুলো প্রথমে প্রোটোটাইপ করুন।

আপনি যদি AppMaster (appmaster.io) দিয়ে তৈরি করে থাকেন, একটি ব্যবহারিক পন্থা হলো core business logic ও ডেটা মডেলগুলি generated ব্যাকএন্ডে রাখা, তারপর শুধুমাত্র সেখানে একটি পাতলা গেটওয়ে বা BFF লেয়ার যোগ করা যেখানে ক্লায়েন্ট সত্যিই আলাদা পে-লোড শেপিং বা রিলিজ আইসোলেশন চায়।

যদি চেকলিস্টের প্রশ্নগুলোর উত্তর দেওয়া কঠিন লাগে, এটাকে একটি সংকেত হিসেবে নিন যে কন্ট্রাক্ট সরল করা এবং পাবলিক বনাম ইন্টারনাল বিভাজন শক্ত করা দরকার বড় এন্ডপয়েন্ট যোগ করার আগে।

প্রশ্নোত্তর

Start with an API gateway when you mainly need one public entry point with shared controls like authentication checks, rate limits, and routing. Add a BFF when web and mobile need noticeably different payloads, fewer client calls, or independent release cycles.

A gateway is best for cross-cutting concerns and traffic control at the edge, so keep it focused on routing, auth enforcement, and basic request/response handling. A BFF should do client-facing composition like combining multiple service calls and trimming fields, but it still shouldn’t become the place where your core business rules live.

A gateway gives you one versioned “front door,” which is simple to explain but can leave you supporting old versions for a long time. A BFF lets you version per client, so mobile can stay stable while web moves faster, at the cost of maintaining more services and contracts.

Prefer non-breaking changes by default, like adding optional fields or adding new endpoints. Create a new version when you remove fields, rename fields, change types, or change meaning, because mobile users may not update for weeks.

Keep internal services private and expose only the gateway or BFF to the public internet. Filter responses so clients only get what they need, and enforce per-route authorization so an internal admin action can’t be reached just because a user is logged in.

Use a BFF when the client would otherwise make many sequential calls, because one server-side aggregation response is often faster than several mobile round trips. A gateway adds an extra hop too, so keep it lightweight and measure latency and payload sizes to avoid hidden slowdowns.

A gateway is a shared choke point, so a bad config or outage can affect every client at once. BFFs reduce blast radius by isolating changes to one client, but you’ll run more deploys, more monitoring, and more on-call surface area.

Use a correlation ID and pass it through the gateway/BFF and all downstream services so one user action is traceable end to end. Track a small set of per-endpoint metrics like error rate, p95 latency, throughput, and payload size so performance regressions show up quickly.

A common trap is letting the gateway accumulate business rules, which makes behavior hard to test and easy to break with a config change. Another is creating too many BFFs (for every screen), which duplicates logic and makes versioning and maintenance painful.

Keep core data models and business processes in the backend you generate, then add a thin gateway or a client-specific BFF only where you truly need shaping or release isolation. In AppMaster, this usually means building stable domain endpoints in the generated Go backend and adding a small layer only for mobile-friendly aggregation or payload trimming.