REST vs GraphQL vs gRPC — प्रत्येक केव्हा निवडाल?

Question

IT Interview Practice · Accepted Answer

हे तीन वेगवेगळे API paradigms आहेत, प्रत्येक वेगळ्या constraints साठी optimize केलेले. कोणीही सार्वत्रिक विजेता नाही — योग्य निवड **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 APIs, CRUD services, आणि 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 सोडवतो. समृद्ध frontends साठी (विशेषतः mobile, जिथे round trips महाग असतात) आणि जेव्हा अनेक clients ना त्याच data चे वेगवेगळे आकार लागतात तेव्हा **ते निवडा**.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
तडजोडी: HTTP caching अधिक कठीण (सर्वकाही `/graphql` ला `POST`), आणि naive resolver महाग `N+1` database queries लपवू शकतो.

## gRPC

**HTTP/2** वर **Protobuf** वापरणारे contract-first RPC. Binary आणि multiplexed, म्हणून streaming support सह वेगवान आणि compact. जिथे performance आणि strict typing महत्त्वाचे आहे अशा microservices backend मधील **अंतर्गत service-to-service** संवादासाठी **ते निवडा**. कमकुवतपणा: खराब browser support (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 स्तरावर, interviewers ना व्याख्यांची कमी आणि तुम्ही **constraints विरुद्ध निवड समर्थन करू शकता** का याची जास्त पर्वा असते — हा प्रश्न प्रत्यक्षात "तुम्ही hype च्या मागे लागण्याऐवजी एखादे तंत्रज्ञान एखाद्या समस्येशी जुळवू शकता का?" असा आहे. सर्वात मजबूत उत्तरे प्रत्येक जण सोडवणाऱ्या दुखण्यावर टेकतात: GraphQL मागणी करणाऱ्या frontends साठी over/under-fetching मारण्यासाठी अस्तित्वात आहे, gRPC अंतर्गत service calls वेगवान आणि strongly typed करण्यासाठी अस्तित्वात आहे, आणि REST default राहते कारण HTTP caching, tooling, आणि सार्वत्रिक परिचय हे public आणि CRUD-style APIs साठी प्रचंड व्यावहारिक फायदे आहेत. महत्त्वाचे म्हणजे, senior engineer नोंदवतो की हे **एक-किंवा-दुसरे नाही** — एक सामान्य architecture म्हणजे public edge ला REST किंवा GraphQL आणि backend microservices दरम्यान gRPC — आणि ठोस trade-offs चे नाव घेतो (GraphQL चे caching आणि `N+1` धोके, gRPC ची कमकुवत browser कथा). योग्यता आणि खर्चाबद्दलचा तो तर्क, features पाठ म्हणण्याची क्षमता नव्हे, हेच signal आहे.

तिन्ही एका दृष्टिक्षेपात

REST

GraphQL

gRPC

निवडणे

हे का महत्त्वाचे आहे

संबंधित प्रश्न