API Gateway: routing ও shared policy
API Gateway
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- API Gateway-এর routing ও shared policy
- Backend-for-Frontend-এর পার্থক্য
- Gateway failure ও ownership boundary
সমস্যা দিয়ে শুরু
Mobile app-কে account, catalog, order ও payment service-এর address জানতে হচ্ছে। প্রতিটিতে token validation আলাদা ও rate limit অসংগত। Gateway একটি external entry point দিয়ে shared request policy ও routing centralize করতে পারে। কিন্তু সব business logic সেখানে ঢুকলে আরেকটি বড় coupled application তৈরি হয়।
সহজ করে বুঝি
API Gateway client request authenticate, route, limit এবং sometimes aggregate করতে পারে। Reverse proxy gateway-এর কিছু কাজ করে; gateway সাধারণত API policy ও client contract-এর ওপর বেশি focus করে। Backend-for-Frontend নির্দিষ্ট client experience-এর tailored aggregation দেয়, যেমন mobile screen-এর ছোট payload। Gateway authentication করলেও backend authorization বাদ দেওয়া যাবে না; service-কে user/tenant permissions বুঝতে হবে বা verified internal identity contract লাগবে।
পরিচিত একটি উপমা
একটি shopping mall-এর information desk visitor-কে সঠিক দোকানে পাঠায় এবং access rules জানায়। Desk পণ্য বানায় না, shop inventory-এর মালিকও নয়। সব দোকানের ব্যবসা desk-এ করলে bottleneck ও দায়িত্বের জটিলতা তৈরি হয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD C[Mobile and Web clients] --> G[Gateway auth routing limits] G --> K[Catalog Service] G --> O[Order Service] G --> P[Payment boundary] K --> D1[(Catalog DB)] O --> D2[(Orders DB)]
Gateway public surface স্থির রাখে; internal service address client জানে না। প্রতিটি arrow-এর timeout ও error mapping নির্ধারণ করুন। Catalog slow হলে order route অপ্রয়োজনীয়ভাবে আটকে যাবে না এমন isolation দরকার। Payment boundary-তে token ও secret handling আলাদা গুরুত্ব পায়। Gateway itself redundant deploy ও monitored হতে হবে।
PHP ও Laravel-এ প্রয়োগ
নিচের controller fragment একটি narrow read aggregation boundary দেখায়, general-purpose proxy নয়। Authenticated route ও authorized account scope আগে enforce করতে হবে। Fixed catalog base URL/token config-এ আছে; arbitrary destination URL client দিতে পারে না। Upstream field শুধু explicit output-এ নেওয়া হয়েছে।
use Illuminate\Support\Facades\Http;
public function catalogSummary()
{
$response = Http::baseUrl(config('services.catalog.url'))
->withToken(config('services.catalog.token'))
->connectTimeout(1)
->timeout(3)
->get('/public/featured');
$response->throw();
$items = $response->json('items');
abort_unless(is_array($items), 502);
return response()->json(['items' => array_map(fn ($item) => [
'id' => $item['id'],
'name' => $item['name'],
], $items)]);
}সুবিধা, সীমাবদ্ধতা ও trade-off
Gateway cross-cutting policy এক করে এবং client migration সহজ করে। Extra network hop, central availability dependency ও config deployment risk যোগ হয়। BFF এক screen-এর request কমাতে পারে, কিন্তু client-specific logic duplicate হতে পারে। Small monolith-এ পৃথক gateway service অপ্রয়োজনীয় হতে পারে; existing reverse proxy ও Laravel middleware যথেষ্ট হলে সেখান থেকে শুরু করুন।
সাধারণ ভুল
- Gateway পেরোলেই সব internal request trusted বলা।
- Upstream সব headers ও errors verbatim client-এ পাঠানো।
- Read aggregation-এর failure-এ সব action endpoint বন্ধ করা।
আরও একটু গভীরে
Gateway থেকে service-এ forwarded identity signed token বা protected channel-এর contract হতে পারে; user-supplied identity header overwrite করতে হবে। Request body/response size সীমা, SSRF defense ও route allowlist লাগবে। Fan-out aggregation-এ end-to-end deadline ভাগ করুন; তিন sequential call প্রতিটির full timeout নিলে total latency budget ভাঙে। Partial response acceptable কি না product decision। Retry layer centralize করলে duplicated retry storm কমতে পারে।
মনে রাখুন
Gateway routing ও policy boundary। Domain ownership backend-এ পরিষ্কার রাখুন। Small system-এ independent gateway না বাড়িয়ে existing middleware/proxy দিয়ে requirement মেটানো যায় কি না দেখুন।
নিজে চেষ্টা করুন
একটি mobile order detail screen-এর account, order ও delivery data flow আঁকুন। কোন failure-এ partial response সম্ভব এবং কোনটিতে পুরো response fail হবে লিখুন। Gateway ও service authorization responsibilities আলাদা table-এ দিন।
নিজের বোঝা যাচাই করুন
1. Gateway আর BFF এক?
এক deployment-এ থাকতে পারে, কিন্তু BFF নির্দিষ্ট client experience-এর tailored contract। Gateway shared routing/policy role পালন করতে পারে।
2. Backend auth লাগবে?
Authorization boundary লাগবেই। Gateway identity verify করলেও service-এর resource-level permission কোথায় enforce হবে স্পষ্ট করতে হবে।
3. Gateway business logic রাখব?
Minimal composition রাখা যায়, কিন্তু core domain invariants কেন্দ্রীয় gateway-এ ছড়ালে coupling বাড়ে। Ownership বিচ্ছিন্ন রাখুন।
4. সব upstream error ফেরত দেব?
না। Consistent external contract map করুন এবং private implementation details বাদ দিন। Internal correlation telemetry আলাদা রাখুন।
5. Small Laravel app-এ লাগবে?
Demonstrated routing/policy requirement না থাকলে আলাদা service দরকার নাও হতে পারে। Reverse proxy ও middleware অনেক প্রাথমিক কাজ মেটায়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।