REST vs GraphQL vs gRPC — ਤੁਸੀਂ ਹਰ ਇੱਕ ਕਦੋਂ ਚੁਣੋਗੇ?

Question

IT Interview Practice · Accepted Answer

ਇਹ ਤਿੰਨ ਵੱਖ-ਵੱਖ API paradigms ਹਨ, ਹਰ ਇੱਕ ਵੱਖ-ਵੱਖ constraints ਲਈ 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-ਅਧਾਰਿਤ। 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 ਨੂੰ ਇੱਕੋ data ਦੇ ਵੱਖ-ਵੱਖ ਆਕਾਰ ਚਾਹੀਦੇ ਹੋਣ ਤਾਂ **ਇਸਨੂੰ ਚੁਣੋ**।

```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** ਸੰਚਾਰ ਲਈ **ਇਸਨੂੰ ਚੁਣੋ** ਜਿੱਥੇ performance ਅਤੇ ਸਖ਼ਤ 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 ਪੱਧਰ 'ਤੇ, ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ definitions ਦੀ ਘੱਟ ਪਰਵਾਹ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਦੀ ਵੱਧ ਕਿ ਕੀ ਤੁਸੀਂ **constraints ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਚੋਣ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕਦੇ ਹੋ** — ਇਹ ਸਵਾਲ ਅਸਲ ਵਿੱਚ ਹੈ "ਕੀ ਤੁਸੀਂ hype ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਦੀ ਬਜਾਏ ਇੱਕ ਤਕਨਾਲੋਜੀ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਨਾਲ ਮਿਲਾ ਸਕਦੇ ਹੋ?" ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਜਵਾਬ ਹਰ ਇੱਕ ਦੁਆਰਾ ਹੱਲ ਕੀਤੇ ਦਰਦ 'ਤੇ ਟਿਕਦੇ ਹਨ: GraphQL ਮੰਗ ਵਾਲੇ frontends ਲਈ over/under-fetching ਨੂੰ ਖ਼ਤਮ ਕਰਨ ਲਈ ਮੌਜੂਦ ਹੈ, gRPC ਅੰਦਰੂਨੀ service calls ਨੂੰ ਤੇਜ਼ ਅਤੇ ਮਜ਼ਬੂਤ ਤੌਰ 'ਤੇ typed ਬਣਾਉਣ ਲਈ ਮੌਜੂਦ ਹੈ, ਅਤੇ REST ਡਿਫ਼ਾਲਟ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ HTTP caching, tooling, ਅਤੇ ਸਰਬਵਿਆਪੀ ਜਾਣ-ਪਛਾਣ public ਅਤੇ CRUD-style APIs ਲਈ ਵੱਡੇ ਵਿਹਾਰਕ ਫ਼ਾਇਦੇ ਹਨ। ਅਹਿਮ ਗੱਲ, ਇੱਕ senior ਇੰਜੀਨੀਅਰ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ਇਹ **either/or ਨਹੀਂ** — ਇੱਕ ਆਮ architecture public edge 'ਤੇ REST ਜਾਂ GraphQL ਹੈ backend microservices ਵਿਚਕਾਰ gRPC ਨਾਲ — ਅਤੇ ਠੋਸ trade-offs ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ (GraphQL ਦੇ caching ਅਤੇ `N+1` ਜੋਖਮ, gRPC ਦੀ ਕਮਜ਼ੋਰ browser ਕਹਾਣੀ)। ਫਿੱਟ ਅਤੇ ਲਾਗਤ ਬਾਰੇ ਉਹ ਤਰਕ, ਨਾ ਕਿ features ਦੁਹਰਾਉਣ ਦੀ ਯੋਗਤਾ, ਹੀ ਸੰਕੇਤ ਹੈ।

ਤਿੰਨਾਂ ਦੀ ਇੱਕ ਝਲਕ

REST

GraphQL

gRPC

ਚੋਣ ਕਰਨਾ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ