Proxy ও API Gateway

Forward proxy, reverse proxy, gateway, BFF

রোডম্যাপের মাস ৩পড়তে প্রায় ৮ মিনিট

"Proxy" মানে প্রতিনিধি, যে কারও হয়ে কাজ করে। Network এ proxy হলো মাঝখানে বসা একটা server, যে request এর হয়ে কথা বলে। কার হয়ে কথা বলছে তার উপর নির্ভর করে দুই রকম: forward proxy (client এর প্রতিনিধি) আর reverse proxy (server এর প্রতিনিধি)। আর API gateway হলো বিশেষ ক্ষমতাওয়ালা reverse proxy, যেটা microservice এর যুগে প্রায় প্রতিটা বড় system এর সামনের দরজা।

#Forward proxy বনাম reverse proxy

Forward proxy: client দের প্রতিনিধি PC ১ PC ২ অফিসের network Proxy Internet যেকোনো site site দেখে শুধু proxy কে, PC গুলোকে না Reverse proxy: server দের প্রতিনিধি User Internet Reverse proxy তোমার data center App server ১ App server ২ user দেখে শুধু proxy কে
Forward proxy client দের লুকায় আর নিয়ন্ত্রণ করে। Reverse proxy server দের লুকায় আর রক্ষা করে।

#Forward proxy

Client এর সামনে বসে। উদাহরণ:

  • অফিস বা স্কুলের network: কোন site খোলা যাবে না সেটা নিয়ন্ত্রণ, সবার traffic log
  • VPN: তোমার আসল IP লুকানো
  • একই জিনিস বারবার নামানো এড়াতে cache (পুরনো ISP proxy)

Backend developer হিসেবে তুমি forward proxy নিয়ে কম কাজ করবে। কখনো কখনো তোমার server থেকে বাইরের API তে যাওয়া সব traffic একটা proxy দিয়ে পাঠাতে হয় (যেমন bank এর API শুধু নির্দিষ্ট IP থেকে request নেয়)।

#Reverse proxy

Server এর সামনে বসে। এটাই backend এর সাথে সরাসরি জড়িত। Nginx, Caddy, HAProxy, Traefik, Envoy, Cloudflare সবই reverse proxy হিসেবে কাজ করে।

Reverse proxy যা যা করে:

কাজ কী লাভ
Load balancing অনেক server এ ভাগ (Load Balancer অধ্যায়)
TLS termination HTTPS এর certificate এক জায়গায়, পেছনের server সহজ HTTP তে
Static file দেওয়া ছবি, CSS, JS সরাসরি proxy দেয়, Python পর্যন্ত যায় না
Compression gzip/brotli দিয়ে response ছোট করা
Cache একই response বারবার না বানিয়ে আগেরটা দেওয়া
Security আসল server এর IP লুকানো, বড় request আটকানো, সাধারণ আক্রমণ ঠেকানো (WAF)
ধীর client সামলানো দুর্বল mobile network এর user আস্তে আস্তে data পাঠালে proxy সেটা জমিয়ে একবারে app server কে দেয়, app এর worker আটকে থাকে না

শেষেরটা বাংলাদেশের প্রেক্ষাপটে গুরুত্বপূর্ণ: 2G/3G বা দুর্বল WiFi তে অনেক user এর upload ধীর। Nginx এর মতো proxy এই ধীর connection নিজে সামলায়, তোমার Python worker গুলো দ্রুত কাজ করে মুক্ত হয়।

#API Gateway: স্মার্ট সামনের দরজা

System যখন অনেকগুলো service এ ভাগ হয় (user service, order service, payment service, notification service), তখন mobile app কি প্রতিটার ঠিকানা আলাদা জানবে? প্রতিটা service কি নিজে login যাচাই করবে? নিজে rate limit করবে? না। এগুলো এক জায়গায় করে API gateway।

Flutter app Web app Partner API API Gateway ১. Authentication (JWT যাচাই) ২. Rate limiting ৩. Routing (কোন service) ৪. Request/response রূপান্তর ৫. Logging, metrics, trace id ৬. Cache, retry, timeout /users → User service /orders → Order service /payments → Payment /notify → Notification
সব client একটাই ঠিকানা জানে। সাধারণ কাজগুলো (login যাচাই, rate limit, log) gateway এক জায়গায় করে, পেছনের service গুলো শুধু নিজের কাজ নিয়ে থাকে।

#Gateway এর কাজ

  1. Routing: URL দেখে ঠিক service এ পাঠানো
  2. Authentication: JWT token যাচাই করে user id টা header এ জুড়ে পেছনে পাঠানো (X-User-Id: 42)। প্রতিটা service কে আলাদা করে token যাচাই করতে হয় না।
  3. Rate limiting: একজন user বা API key মিনিটে কতবার call করতে পারবে (Rate Limiting)
  4. রূপান্তর: পুরনো app এর request কে নতুন format এ বদলানো, কয়েকটা service এর উত্তর মিলিয়ে একটা response বানানো (aggregation)
  5. Observability: প্রতিটা request এ একটা trace id দেওয়া, যাতে পরে পুরো যাত্রা খুঁজে পাওয়া যায় (Observability)
  6. Resilience: timeout, retry, circuit breaker (Resilience)

উদাহরণ: Kong, AWS API Gateway, Apigee, Tyk, Envoy-ভিত্তিক gateway, Cloudflare।

#BFF: Backend For Frontend

Mobile app আর web app এর data এর চাহিদা আলাদা। Mobile এ ছোট screen, কম data, দুর্বল network। Web এ বড় dashboard। একই API দিয়ে দুইজনকে খুশি করা কঠিন। সমাধান BFF: প্রতিটা ধরনের client এর জন্য আলাদা একটা পাতলা backend স্তর।

Text
Flutter app  →  Mobile BFF  ─┐
                              ├→  User / Order / Payment service
Web app      →  Web BFF     ─┘

Mobile BFF হয়তো order details screen এর জন্য ৩টা service call করে এক response এ শুধু দরকারি ১০টা field দেয়। ফলে mobile এ এক request, কম data। GraphQL ও প্রায়ই এই কাজে ব্যবহার হয়।

#সাবধানতা

  • Single point of failure: gateway নষ্ট মানে সব বন্ধ। তাই একাধিক instance আর managed service।
  • বাড়তি latency: প্রতিটা request এ একটা বাড়তি ধাপ (সাধারণত কয়েক ms)। সাধারণত চলে, কিন্তু অনেক স্তরের proxy জমলে যোগ হয়ে যায়।
  • ছোট system এ দরকার নেই। একটা FastAPI monolith এর জন্য Nginx বা Cloudflare এর মতো reverse proxy যথেষ্ট। আলাদা API gateway আসে অনেকগুলো service হলে।

#তোমার project এ বাস্তবে

পর্যায় সামনে কী থাকবে
শুরু (একটা FastAPI app) Platform এর দেওয়া proxy (Railway, Render, Fly), বা একটা Nginx/Caddy
কয়েকটা server Managed load balancer বা Nginx, সামনে Cloudflare (CDN + DDoS সুরক্ষা)
অনেক service API gateway + service গুলোর ভেতরের যোগাযোগের জন্য আলাদা ব্যবস্থা

#অনুশীলন

#নিজেকে যাচাই করো

Forward আর reverse proxy এর পার্থক্য এক বাক্যে বলো।

Forward proxy client দের পক্ষে বাইরের দুনিয়ার সাথে কথা বলে (client লুকায়), reverse proxy server দের পক্ষে বাইরের দুনিয়ার সাথে কথা বলে (server লুকায়)।

Reverse proxy দুর্বল mobile network এর user দের ক্ষেত্রে app server কে কীভাবে সাহায্য করে?

ধীর connection থেকে আস্তে আস্তে আসা data proxy নিজে জমা করে, পুরোটা এলে একবারে app server কে দেয়। ফলে app এর worker ধীর user এর জন্য আটকে বসে থাকে না।

API gateway তে কোন ধরনের কাজ রাখা উচিত না?

Business logic, যেমন দাম হিসাব বা order এর নিয়ম। Gateway তে শুধু সবার জন্য সাধারণ কাজ (routing, authentication, rate limit, log)। না হলে gateway জটিল আর সবার জন্য বাধা হয়ে যায়।

BFF কী সমস্যা সমাধান করে?

বিভিন্ন ধরনের client (mobile, web) এর data এর চাহিদা আলাদা। BFF প্রতিটা client এর জন্য একটা পাতলা স্তর দেয় যেটা কয়েকটা service এর data মিলিয়ে ঠিক সেই client এর দরকার মতো response বানায়, ফলে কম request আর কম data।

চিহ্ন দিলে sidebar আর রোডম্যাপে এই অধ্যায়ের station ভরে যাবে।