REST بمقابلہ GraphQL بمقابلہ gRPC — آپ ہر ایک کو کب چنیں گے؟

Question

IT Interview Practice · Accepted Answer

یہ تین مختلف API paradigms ہیں، ہر ایک مختلف پابندیوں کے لیے بہتر بنایا گیا ہے۔ کوئی آفاقی فاتح نہیں ہے — درست انتخاب **صارف، ڈیٹا کی شکل، اور نیٹ ورک** پر منحصر ہے۔

## ایک نظر میں تینوں

```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 پر مبنی۔ **اسے چنیں** public APIs، CRUD services، اور کسی بھی ایسی چیز کے لیے جو HTTP caching، ہمہ گیریت، اور سادگی سے فائدہ اٹھاتی ہو۔ اس کی کمزوریاں **over-fetching** ہیں (آپ کو پورا `/users/42` ملتا ہے چاہے آپ کو ایک field چاہیے) اور **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 حل کرتے ہوئے۔ **اسے چنیں** بھرپور frontends کے لیے (خاص طور پر mobile، جہاں round trips مہنگے ہیں) اور جب بہت سے clients کو ایک ہی ڈیٹا کی مختلف شکلیں درکار ہوں۔

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Trade-offs: HTTP caching مشکل تر ہے (ہر چیز `/graphql` کو ایک `POST` ہے)، اور ایک سادہ لوح resolver مہنگی `N+1` database queries چھپا سکتا ہے۔

## gRPC

**HTTP/2** پر **Protobuf** استعمال کرتے ہوئے contract-first RPC۔ Binary اور multiplexed، اس لیے یہ streaming سپورٹ کے ساتھ تیز اور کمپیکٹ ہے۔ **اسے چنیں** کسی microservices backend میں **اندرونی service-to-service** رابطے کے لیے جہاں پرفارمنس اور سخت typing اہم ہو۔ کمزوری: کمزور browser سپورٹ (grpc-web جیسے proxy کی ضرورت) اور انسان کے پڑھنے کے قابل نہیں۔

## انتخاب

```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 سطح پر، انٹرویو لینے والوں کو تعریفوں سے کم اور اس بات سے زیادہ سروکار ہوتا ہے کہ آیا آپ **کسی انتخاب کو پابندیوں کے خلاف جواز فراہم** کر سکتے ہیں — یہ سوال دراصل ہے "کیا آپ hype کا پیچھا کرنے کے بجائے کسی ٹیکنالوجی کو کسی مسئلے سے ملا سکتے ہیں؟" سب سے مضبوط جوابات اس درد پر لنگر ڈالتے ہیں جو ہر ایک حل کرتا ہے: GraphQL مطالبہ کرنے والے frontends کے لیے over/under-fetching کو ختم کرنے کے لیے موجود ہے، gRPC اندرونی service calls کو تیز اور مضبوط typed بنانے کے لیے موجود ہے، اور REST بطور default رہتا ہے کیونکہ HTTP caching، tooling، اور آفاقی واقفیت public اور CRUD طرز کی APIs کے لیے زبردست عملی فوائد ہیں۔ نہایت اہم، ایک senior انجینئر نوٹ کرتا ہے کہ یہ **یا تو/یا** نہیں ہے — ایک عام ساخت public edge پر REST یا GraphQL اور backend microservices کے درمیان gRPC ہے — اور ٹھوس trade-offs کے نام لیتا ہے (GraphQL کے caching اور `N+1` خطرات، gRPC کی کمزور browser کہانی)۔ فٹ اور لاگت کے بارے میں وہی استدلال، نہ کہ خصوصیات دہرانے کی صلاحیت، اصل اشارہ ہے۔

ایک نظر میں تینوں

REST

GraphQL

gRPC

انتخاب

یہ کیوں اہم ہے

متعلقہ سوالات