REST vs GraphQL vs gRPC — ஒவ்வொன்றையும் எப்போது தேர்ந்தெடுப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

இவை மூன்று வெவ்வேறு API paradigms, ஒவ்வொன்றும் வெவ்வேறு constraints-க்கு optimize செய்யப்பட்டது. உலகளாவிய வெற்றியாளர் இல்லை — சரியான தேர்வு **நுகர்வோர், data shape, மற்றும் 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

Plain 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

**Client சரியாக என்ன வேண்டும் என்பதைக் குறிப்பிடும்** ஒரு single endpoint, ஒரு query-இல், over/under-fetching-ஐத் தீர்க்கிறது. Rich frontends-க்கு (குறிப்பாக mobile, round trips விலையுயர்ந்த இடம்) மற்றும் பல clients-க்கு அதே data-இன் வெவ்வேறு shapes தேவைப்படும்போது **அதைத் தேர்ந்தெடுங்கள்**.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Trade-offs: HTTP caching கடினமானது (எல்லாம் `/graphql`-க்கு ஒரு `POST`), மற்றும் ஒரு naive resolver விலையுயர்ந்த `N+1` database queries-ஐ மறைக்கலாம்.

## gRPC

**HTTP/2** மீது **Protobuf** பயன்படுத்தும் contract-first RPC. Binary மற்றும் multiplexed, எனவே streaming ஆதரவுடன் வேகமானது மற்றும் சிறியது. performance மற்றும் strict typing முக்கியமான ஒரு microservices backend-இல் **internal service-to-service** communication-க்கு **அதைத் தேர்ந்தெடுங்கள்**. பலவீனம்: மோசமான 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 level-இல், interviewers வரையறைகளைப் பற்றி குறைவாகவும், constraints-க்கு எதிராக ஒரு தேர்வை **நியாயப்படுத்த** முடியுமா என்பதைப் பற்றி அதிகமாகவும் அக்கறை கொள்கிறார்கள் — இந்தக் கேள்வி உண்மையில் "hype-ஐ துரத்துவதற்குப் பதிலாக ஒரு technology-ஐ ஒரு சிக்கலுக்குப் பொருத்த முடியுமா?". வலுவான பதில்கள் ஒவ்வொன்றும் தீர்க்கும் வலியில் நங்கூரமிடுகின்றன: over/under-fetching-ஐ கோரும் frontends-க்குக் கொல்ல GraphQL உள்ளது, internal service calls-ஐ வேகமாகவும் strongly typed-ஆகவும் ஆக்க gRPC உள்ளது, மற்றும் HTTP caching, tooling, மற்றும் உலகளாவிய பரிச்சயம் public மற்றும் CRUD-style APIs-க்கு மகத்தான நடைமுறை நன்மைகள் என்பதால் REST இயல்புநிலையாக உள்ளது. முக்கியமாக, ஒரு senior engineer இது **இரண்டில் ஒன்று அல்ல** என்பதைக் குறிப்பிடுகிறார் — ஒரு பொதுவான architecture public edge-இல் REST அல்லது GraphQL-உடன் backend microservices-க்கு இடையே gRPC — மேலும் உறுதியான trade-offs-ஐப் பெயரிடுகிறார் (GraphQL-இன் caching மற்றும் `N+1` அபாயங்கள், gRPC-இன் பலவீன browser கதை). Features-ஐ ஒப்பிக்கும் திறமை அல்ல, பொருத்தம் மற்றும் செலவைப் பற்றிய அந்தச் சிந்தனையே சமிக்ஞை.

மூன்றையும் ஒரு பார்வையில்

REST

GraphQL

gRPC

தேர்ந்தெடுத்தல்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்