API Design & Gateway
API Design কী এবং কেন Design Matter করে?
API (Application Programming Interface) হলো দুটো system এর মধ্যে communication এর চুক্তি। ধরুন একটা restaurant এর menu — আপনি menu দেখে order করুন, kitchen কীভাবে বানায় সেটা আপনাকে জানতে হয় না। API ও ঠিক তাই — client কী চাইতে পারে এবং server কী দেবে সেটা define করে।
API Design কেন গুরুত্বপূর্ণ
ভালো API design মানে developer-friendly, predictable, consistent। খারাপ API মানে confusion, bugs, maintenance nightmare। Twitter এর API v1 থেকে v2 migration developers দের কাঁদিয়েছে। Good design upfront সেই pain বাঁচায়।
REST — Representational State Transfer
REST হলো সবচেয়ে popular API style। HTTP methods ব্যবহার করে resources manipulate করে। Stateless, cacheable, uniform interface — এই principles এ কাজ করে।
REST HTTP Methods
| Method | Action | Example URL | Body? |
|---|---|---|---|
| GET | Read data | GET /users/123 | No |
| POST | Create new | POST /users | Yes |
| PUT | Replace full | PUT /users/123 | Yes |
| PATCH | Partial update | PATCH /users/123 | Yes |
| DELETE | Delete | DELETE /users/123 | No |
HTTP Status Codes
| Status Code | মানে | কখন |
|---|---|---|
| 200 OK | Success | GET, PUT, PATCH success |
| 201 Created | New resource created | POST success |
| 400 Bad Request | Client error | Invalid input |
| 401 Unauthorized | Auth required | No/invalid token |
| 403 Forbidden | Permission denied | Valid token but no access |
| 404 Not Found | Resource missing | User/product not exist |
| 429 Too Many Requests | Rate limit exceeded | Too many API calls |
| 500 Server Error | Server bug | Unexpected crash |
REST Design Rules
Nouns use করুন, verbs না: /users ভালো, /getUsers খারাপ। Plural use করুন: /users, /products। Nesting: /users/123/orders। Versioning: /api/v1/users। HTTP status codes সঠিকভাবে use করুন।
GraphQL — Query Language for APIs
Facebook তৈরি করেছেনে। Client exactly যেটুকু data চায় সেটুকুই request করতে পারে — over-fetching বা under-fetching নেই। একটা endpoint, flexible queries।
REST Problem
User profile page এ name, avatar দরকার। GET /users/123 → পুরো object আসে (email, phone, address সব)। Over-fetching! আবার, posts ও দরকার হলে আরেকটা request। Under-fetching!
GraphQL Solution
একটা query তে exactly যা দরকার: { user(id: 123) { name avatar posts { title } } } — শুধু name, avatar, এবং post titles আসবেন। একটা request এ সব।
# REST এ এটার জন্য 3টা API call লাগতো
# GraphQL এ একটাই
query GetUserDashboard {
user(id: "123") {
name
avatar
posts(first: 5) {
title
createdAt
}
followers {
count
}
}
}
# Mutation — data change করতে
mutation UpdateProfile($name: String!, $bio: String) {
updateUser(input: { name: $name, bio: $bio }) {
id
name
updatedAt
}
}GraphQL এর Downside
Caching complex (REST এর মতো URL-based cache কাজ করে না)। N+1 query problem (DataLoader দিয়ে solve করতে হয়)। Simple CRUD apps এ overkill। REST এর মতো HTTP cache/CDN সুবিধা নেই।
gRPC — High Performance RPC
Google তৈরি করেছেনে। Protocol Buffers (protobuf) দিয়ে data serialize করে — JSON এর চেয়ে ৫-১০x faster। Strongly typed, code generation, bidirectional streaming। Microservices internal communication এর জন্য ideal।
// Service definition
syntax = "proto3";
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
rpc ListUsers (ListRequest) returns (stream UserResponse);
}
message UserRequest {
string user_id = 1;
}
message UserResponse {
string id = 1;
string name = 2;
string email = 3;
int32 age = 4;
}
// protoc দিয়ে Python/Go/Java/Node code generate হবেREST vs GraphQL vs gRPC — তুলনা
| Feature | REST | GraphQL | gRPC |
|---|---|---|---|
| Protocol | HTTP/1.1 | HTTP/1.1 | HTTP/2 |
| Data Format | JSON | JSON | Binary (Protobuf) |
| Performance | Good | Good | Excellent |
| Over-fetching | Yes | No | No (typed) |
| Browser Support | Native | Native | Limited (grpc-web) |
| Best For | Public APIs, CRUD | Complex data, mobile | Microservices, low-latency |
| Learning Curve | Easy | Medium | Hard |
API Gateway — Single Entry Point
Microservices architecture এ ৫০টা service আছে। Client কি ৫০টা আলাদা URL জানবেন? না। API Gateway হলো single entry point — সব requests এখান দিয়ে ঢোকে, Gateway সঠিক service এ route করে।
API Gateway Features
Authentication: JWT token verify করে, backend services কে auth চিন্তা করতে হয় না। Rate Limiting: প্রতি user/IP কতটা request করতে পারবেন limit করে। Request Transformation: Request/response format modify করতে পারে। Circuit Breaking: Backend service fail হলে fast-fail করে। Popular tools: AWS API Gateway, Kong, Nginx, Traefik।
Code Examples
Node.js — REST API with Express
const express = require('express');
const app = express();
app.use(express.json());
// GET /api/v1/users/:id
app.get('/api/v1/users/:id', async (req, res) => {
try {
const user = await User.findById(req.params.id);
if (!user) return res.status(404).json({
error: 'User not found', code: 'USER_NOT_FOUND'
});
res.status(200).json({ data: user });
} catch (err) {
res.status(500).json({ error: 'Internal server error' });
}
});
// POST /api/v1/users — create user
app.post('/api/v1/users', async (req, res) => {
const { name, email, password } = req.body;
if (!name || !email) return res.status(400).json({
error: 'name and email required'
});
const user = await User.create({ name, email, password });
res.status(201).json({ data: user });
});
// PATCH /api/v1/users/:id — partial update
app.patch('/api/v1/users/:id', async (req, res) => {
const updated = await User.findByIdAndUpdate(
req.params.id, req.body, { new: true }
);
res.json({ data: updated });
});Rate Limiting Middleware
const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
// API Rate limit: 100 requests per 15 minutes per IP
const apiLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100,
standardHeaders: true,
store: new RedisStore({ client: redisClient }),
handler: (req, res) => {
res.status(429).json({
error: 'Too many requests',
retryAfter: Math.ceil(res.getHeader('Retry-After'))
});
}
});
app.use('/api/', apiLimiter);Interview Preparation — Common Questions
Q1: REST vs GraphQL কখন ব্যবহার করবেন?
উত্তর:"Better" নির্ভর করে use case এ। REST — simple CRUD, public API, caching important। GraphQL — complex data requirements, mobile app (bandwidth sensitive), multiple clients different data চাই। Interview এ দুটোর trade-off বলুন।
Q2: Rate Limiting কীভাবে implement করবেন?
উত্তর: Token Bucket বা Sliding Window algorithm ব্যবহার করি। Redis এ per-user counter রাখি। Express এ express-rate-limit + RedisStore। Limit exceed হলে 429 Too Many Requests return করি, Retry-After header সহ। API Gateway level এ (Kong/AWS) করলেন service কে বিরক্ত করতে হয় না।
Q3: API versioning কীভাবে করবেন?
উত্তর: ৩টা approach: URL versioning (/api/v1/ → সবচেয়ে common, visible)। Header versioning (Accept: application/vnd.api+json;version=1 → cleaner URLs)। Query param (?version=1 → easy but messy)। URL versioning সবচেয়ে popular কারণ explicit এবং debuggable।
SUMMARY — আজকে যা শিখলাম
| Concept | এক লাইনে |
|---|---|
| REST | HTTP methods + nouns. Stateless, cacheable, widely supported |
| GraphQL | Client decides what data it needs. No over/under-fetching |
| gRPC | Binary, fast, typed. Internal microservices এর জন্য best |
| API Gateway | Single entry point. Auth, rate limit, routing centralized |
| Rate Limiting | Abuse prevent করুন, 429 Too Many Requests দিন |
| Status Codes | 2xx success, 4xx client error, 5xx server error |
| API Versioning | URL path versioning (/api/v1/) সবচেয়ে popular এবং explicit |