REST बनाम GraphQL बनाम gRPC — आप हर एक को कब चुनेंगे?

Question

IT Interview Practice · Accepted Answer

ये तीन अलग-अलग API paradigms हैं, हर एक अलग constraints के लिए अनुकूलित। कोई सार्वभौमिक विजेता नहीं है — सही choice **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** (आपको पूरा `/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 में **internal 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 स्तर पर, interviewers परिभाषाओं की कम और इसकी अधिक परवाह करते हैं कि क्या आप **constraints के विरुद्ध एक choice को उचित ठहरा सकते हैं** — यह सवाल असल में है "क्या आप hype के पीछे भागने के बजाय एक technology को एक समस्या से मिला सकते हैं?" सबसे मज़बूत जवाब उस दर्द पर टिके होते हैं जो हर एक हल करता है: GraphQL माँग वाले frontends के लिए over/under-fetching को मारने के लिए मौजूद है, gRPC internal service calls को तेज़ और strongly typed बनाने के लिए मौजूद है, और REST default बना रहता है क्योंकि HTTP caching, tooling, और सार्वभौमिक परिचितता public व CRUD-शैली APIs के लिए विशाल व्यावहारिक लाभ हैं। महत्वपूर्ण रूप से, एक senior engineer नोट करता है कि यह **या-तो/या नहीं** है — एक आम architecture है public edge पर REST या GraphQL साथ backend microservices के बीच gRPC — और ठोस trade-offs नाम लेता है (GraphQL के caching और `N+1` जोखिम, gRPC की कमज़ोर browser कहानी)। फिट और cost के बारे में वह तर्क, न कि features दोहराने की क्षमता, ही संकेत है।

तीनों एक नज़र में

REST

GraphQL

gRPC

चुनना

यह क्यों महत्वपूर्ण है

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