REST-க்குப் பதிலாக GraphQL-ஐ எப்போது தேர்ந்தெடுப்பீர்கள், எப்போது தேர்ந்தெடுக்க மாட்டீர்கள்?

Question

IT Interview Practice · Accepted Answer

**API-ஐ யார் நுகர்கிறார்கள் மற்றும் அவர்களின் data தேவைகள் எவ்வளவு பன்முகத்தன்மை கொண்டவை** என்பதன் அடிப்படையில் தேர்ந்தெடுங்கள் — hype-ன் அடிப்படையில் அல்ல. பல பன்முக client-கள் தங்கள் சொந்த data-வை வடிவமைக்க வேண்டியிருக்கும்போது GraphQL வெற்றி பெறுகிறது; request-கள் uniform, cacheable, மற்றும் எளிமையாக இருக்கும்போது REST வெற்றி பெறுகிறது.

## GraphQL-ஐ எப்போது தேர்ந்தெடுப்பது

- **வெவ்வேறு தேவைகள் கொண்ட பல client-கள்** — web, iOS, Android ஒவ்வொன்றும் அதே entity-களிலிருந்து வெவ்வேறு fields-ஐ விரும்புகின்றன. GraphQL over/under-fetching-ஐ கொல்கிறது, எனவே ஒவ்வொரு screen-க்கும் நீங்கள் ஒரு புதிய endpoint-ஐ ship செய்யத் தேவையில்லை.
- **ஆழமாக தொடர்புடைய/graph-like data** — ஒரு query, N REST round trip-களுக்குப் பதிலாக relationship-களை (`user -> posts -> comments`) traverse செய்கிறது.
- **விரைவான product iteration** — additive schema evolution, புதிய backend endpoint-கள் அல்லது version-களுக்காகக் காத்திராமல் frontend team-கள் fields சேர்க்க அனுமதிக்கிறது.
- **Microservice-களை aggregate செய்தல்** — ஒரு federated gateway பல service-கள் மீது ஒரு graph-ஐ முன்வைக்கிறது (ஒரு BFF pattern).

## REST-ஐ எப்போது தேர்ந்தெடுப்பது

- **எளிய, uniform resource-கள்** கணிக்கக்கூடிய access-உடன் — ஒவ்வொரு client-ம் அதே வடிவத்தை விரும்பும் CRUD.
- **HTTP caching / CDN மிக முக்கியம்** — REST-இன் URL + `GET` model ஒவ்வொரு அடுக்கிலும் அற்பமாக cache ஆகிறது; GraphQL நெருங்க persisted queries தேவை.
- **File upload/download, binary, அல்லது public API-கள்** அங்கு பரந்த tooling, status code-கள், மற்றும் எளிமை வெற்றி பெறுகின்றன.
- **சிறிய team / குறைந்த complexity** — சில endpoint-களுக்காக GraphQL-இன் server-side cost (resolvers, N+1 control, query-cost limits, schema tooling) மதிப்புக்குரியதல்ல.

## நேர்மையான trade-off அட்டவணை

| Concern | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Solved by design | Common problem |
| HTTP/CDN caching | Hard (needs work) | Native and easy |
| Query-cost/DoS control | You must add it | Naturally bounded |
| Client flexibility | High | Low |
| Server complexity | Higher | Lower |

அவை பரஸ்பரம் exclusive-ம் அல்ல — பல system-கள் public/cacheable endpoint-களுக்கு REST-ஐயும், வளமான internal client-களுக்கு GraphQL-ஐயும் வெளிப்படுத்துகின்றன.

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

Senior interviewer-கள் **விசுவாசத்தை அல்ல, தீர்ப்பாற்றலை** சோதிக்கிறார்கள். வலிமையான பதில் அச்சுகளைப் பெயரிடுகிறது — client பன்முகத்தன்மை, caching தேவைகள், team முதிர்ச்சி, DoS surface — மேலும் GraphQL-ஐ உலகளாவிய ரீதியில் சிறந்தது என்று விற்பதற்குப் பதிலாக அதன் உண்மையான செலவுகளை (caching மற்றும் query-cost control) ஒப்புக்கொள்கிறது.

Concern	GraphQL	REST
Over/under-fetching	Solved by design	Common problem
HTTP/CDN caching	Hard (needs work)	Native and easy
Query-cost/DoS control	You must add it	Naturally bounded
Client flexibility	High	Low
Server complexity	Higher	Lower

GraphQL-ஐ எப்போது தேர்ந்தெடுப்பது

REST-ஐ எப்போது தேர்ந்தெடுப்பது

நேர்மையான trade-off அட்டவணை

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

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