REST vs GraphQL vs gRPC — तपाईं प्रत्येक कहिले छान्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

यी तीन फरक API paradigm हुन्, प्रत्येक फरक constraint का लागि अनुकूलित। कुनै विश्वव्यापी विजेता छैन — सही छनोट **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। सार्वजनिक 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

एउटा single 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
```
Trade-off: HTTP caching गाह्रो हुन्छ (सबै कुरा `/graphql` मा एउटा `POST` हो), र naive resolver ले महँगो `N+1` database query लुकाउन सक्छ।

## gRPC

**HTTP/2** माथि **Protobuf** प्रयोग गरेर contract-first RPC। Binary र multiplexed, त्यसैले यो streaming समर्थनसहित छिटो र सघन छ। performance र कडा typing महत्त्वपूर्ण हुने microservices backend मा **आन्तरिक service-to-service** सञ्चारका लागि **यो छान्नुहोस्**। कमजोरी: कमजोर 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 स्तरमा, interviewer हरूले परिभाषामा भन्दा तपाईं **constraint विरुद्ध एउटा छनोट औचित्य ठहराउन** सक्नुहुन्छ कि भन्नेमा बढी वास्ता गर्छन् — यो प्रश्न वास्तवमा "तपाईं hype पछ्याउनुको सट्टा technology लाई problem सँग मिलाउन सक्नुहुन्छ?" हो। सबैभन्दा बलिया जवाफहरू प्रत्येकले समाधान गर्ने पीडामा टिक्छन्: GraphQL माग गर्ने frontend का लागि over/under-fetching मार्न अस्तित्वमा छ, gRPC आन्तरिक service call लाई छिटो र कडा typed बनाउन अस्तित्वमा छ, र REST default नै रहन्छ किनभने HTTP caching, tooling, र विश्वव्यापी परिचितता सार्वजनिक र CRUD-शैलीका API का लागि विशाल व्यावहारिक फाइदा हुन्। महत्त्वपूर्ण कुरा, एउटा senior engineer ले यो **या त/या** होइन भन्ने उल्लेख गर्छ — एउटा सामान्य architecture भनेको सार्वजनिक edge मा REST वा GraphQL र backend microservice हरूबीच gRPC हो — र ठोस trade-off (GraphQL को caching र `N+1` जोखिम, gRPC को कमजोर browser कथा) नाम दिन्छ। सुविधा र लागत बारेको त्यो तर्क, feature रटाउन सक्ने क्षमता होइन, नै सङ्केत हो।

एक नजरमा तीनवटा

REST

GraphQL

gRPC

छनोट गर्दै

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू