ஒரு GraphQL API-ஐ நீங்கள் எவ்வாறு cache செய்கிறீர்கள்?

Question

IT Interview Practice · Accepted Answer

GraphQL-ஐ cache செய்வது REST-ஐ விடக் கடினம், ஏனெனில் ஒரே endpoint மட்டுமே உள்ளது மற்றும் request-கள் பொதுவாக POST ஆக இருக்கின்றன, எனவே URL-based HTTP caching அப்படியே வேலை செய்யாது. அதற்குப் பதிலாக நீங்கள் மூன்று அடுக்குகளில் cache செய்கிறீர்கள்: **client**, **transport/CDN**, மற்றும் **server**.

## Normalized client cache

Apollo Client மற்றும் Relay, முடிவுகளை `__typename` + `id` மூலம் key செய்யப்பட்ட ஒரு **normalized cache**-இல் சேமிக்கின்றன. ஒவ்வொரு object-ம் ஒரு முறை சேமிக்கப்படுகிறது; அதே `User:1`-ஐ குறிப்பிடும் வெவ்வேறு query-கள் அதைப் பகிர்ந்துகொள்கின்றன, எனவே ஒரு entity-ஐ update செய்யும் ஒரு mutation, ஒவ்வொரு view-ஐயும் தானாகவே refresh செய்கிறது.

```graphql
# Both queries write to the same normalized entry User:1 in the client cache
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author is also User:1
```

இதனால்தான் field-கள் `id`-ஐத் திருப்பி அனுப்ப வேண்டும் — deduplicate செய்ய cache-க்கு ஒரு நிலையான key தேவை.

## Persisted query-கள் + CDN

**Persisted query**-கள் query string-ஐ ஒரு hash-ஆல் மாற்றுகின்றன. Client ஒரு நீண்ட POST body-க்குப் பதிலாக ஒரு குறுகிய hash-ஐ அனுப்புகிறது; server பதிவுசெய்யப்பட்ட query-ஐத் தேடுகிறது.

```js
// Automatic Persisted Queries: first a tiny GET with just the hash
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> because it's a GET with a stable key, a CDN can cache the RESPONSE at the edge
```

Read query-களை cache செய்யக்கூடிய GET-களாக மாற்றுவது ஒரு **CDN** அவற்றை edge-இல் serve செய்ய அனுமதிக்கிறது, மேலும் payload-களைச் சுருக்குகிறது. `@cacheControl` hint-கள் (max-age, scope), CDN மற்றும் Apollo server cache மதிக்கும் per-field TTL-களை server அறிவிக்க அனுமதிக்கின்றன.

## Server-side

Query + variables + auth scope மூலம் key செய்யப்பட்ட ஒரு response cache (எ.கா. Apollo-வின்), resolver-களை மீண்டும் இயக்குவதைத் தவிர்க்கிறது; DataLoader per-request de-duplication-ஐக் கையாள்கிறது (இது வேறு ஒரு கவலை — இது ஒரு cross-request cache அல்ல).

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

Single-endpoint/POST design, அப்பட்டமான HTTP caching-ஐ உடைக்கிறது, எனவே interviewer-கள் **அடுக்கு (layered)** பதிலைக் கேட்க விரும்புகிறார்கள்: client-இல் normalized entity cache, CDN/edge caching-ஐ திறக்க persisted queries + `@cacheControl`, மேலும் DataLoader எங்கு பொருந்துகிறது (per-request, cross-request அல்ல).

Normalized client cache

Persisted query-கள் + CDN

Server-side

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

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