REST vs GraphQL vs gRPC — কখন আপনি কোনটি বেছে নেবেন?

Question

IT Interview Practice · Accepted Answer

এগুলো তিনটি ভিন্ন API paradigm, প্রতিটি ভিন্ন constraint-এর জন্য optimized। কোনো সর্বজনীন বিজয়ী নেই — সঠিক পছন্দ **consumer, data-র আকৃতি, আর network**-এর ওপর নির্ভর করে।

## এক নজরে তিনটি

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

সাধারণ HTTP-র ওপর resource-oriented। public API, CRUD service, এবং HTTP caching, সর্বব্যাপীতা, ও সরলতা থেকে উপকৃত যেকোনো কিছুর জন্য **এটি বেছে নিন**। এর দুর্বলতা হলো **over-fetching** (আপনি একটি field দরকার হলেও পুরো `/users/42` পান) আর **under-fetching** (`N+1` সমস্যা: একটি user আনুন, তারপর প্রতিটি order আনতে loop করুন)।

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

একটি একক endpoint যেখানে **client ঠিক কী চায় তা নির্দিষ্ট করে** একটি query-তে, over/under-fetching সমাধান করে। রিচ frontend-এর জন্য (বিশেষত mobile, যেখানে round trip ব্যয়বহুল) এবং যখন অনেক client একই data-র ভিন্ন আকৃতি চায় তখন **এটি বেছে নিন**।

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
ট্রেড-অফ: HTTP caching কঠিন (সবকিছু `/graphql`-এ একটি `POST`), এবং একটি সরল resolver ব্যয়বহুল `N+1` database query লুকাতে পারে।

## gRPC

**HTTP/2**-এর ওপর **Protobuf** ব্যবহার করে contract-first RPC। Binary আর multiplexed, তাই streaming সমর্থন সহ দ্রুত ও compact। একটি microservices backend-এ **অভ্যন্তরীণ service-to-service** যোগাযোগের জন্য যেখানে performance আর কঠোর typing গুরুত্বপূর্ণ সেখানে **এটি বেছে নিন**। দুর্বলতা: দুর্বল browser সমর্থন (grpc-web-এর মতো একটি proxy দরকার) এবং human-readable নয়।

## বেছে নেওয়া

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## এটি কেন গুরুত্বপূর্ণ

Senior স্তরে, interviewer-রা সংজ্ঞা নিয়ে কম মাথা ঘামান আর আপনি **constraint-এর বিপরীতে একটি পছন্দ যুক্তিসঙ্গত করতে** পারেন কিনা তা নিয়ে বেশি — এই প্রশ্ন আসলে "আপনি hype-এর পেছনে না ছুটে একটি সমস্যার সাথে একটি প্রযুক্তি মেলাতে পারেন কি?"। সবচেয়ে শক্তিশালী উত্তর প্রতিটির সমাধান করা ব্যথায় নোঙর করে: GraphQL চাহিদাসম্পন্ন frontend-এর জন্য over/under-fetching মারতে বিদ্যমান, gRPC অভ্যন্তরীণ service call দ্রুত ও দৃঢ়ভাবে typed করতে বিদ্যমান, আর REST default থেকে যায় কারণ HTTP caching, tooling, ও সর্বজনীন পরিচিতি public ও CRUD-ধরনের API-র জন্য বিশাল ব্যবহারিক সুবিধা। গুরুত্বপূর্ণভাবে, একজন senior engineer লক্ষ্য করেন এটি **হয়/অথবা নয়** — একটি সাধারণ architecture হলো public edge-এ REST বা GraphQL সাথে backend microservice-এর মধ্যে gRPC — এবং সুনির্দিষ্ট ট্রেড-অফ নাম দেন (GraphQL-এর caching ও `N+1` ঝুঁকি, gRPC-র দুর্বল browser গল্প)। ফিট আর খরচ নিয়ে সেই যুক্তি, feature আওড়ানোর ক্ষমতা নয়, সেটাই সংকেত।

এক নজরে তিনটি

REST

GraphQL

gRPC

বেছে নেওয়া

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন