Cachování GraphQL je těžší než u REST, protože je zde jeden endpoint a požadavky bývají POST, takže HTTP cachování založené na URL nefunguje bez dalšího. Místo toho cachujete ve třech vrstvách: klient, transport/CDN a server.
Apollo Client a Relay ukládají výsledky do klíčované podle + . Každý objekt je uložen jednou; různé dotazy, které odkazují na tentýž , jej sdílejí, takže mutace aktualizující jednu entitu automaticky obnoví každé zobrazení.
__typenameidUser:1# Oba dotazy zapisují do stejného normalizovaného záznamu User:1 v klientské cache
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } } # author je také User:1
Proto by pole měla vracet id — cache potřebuje stabilní klíč pro deduplikaci.
Persisted queries nahrazují řetězec dotazu hashem. Klient posílá krátký hash místo dlouhého POST těla; server vyhledá zaregistrovaný dotaz.
// Automatic Persisted Queries: nejprve drobný GET jen s hashem
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> protože je to GET se stabilním klíčem, může CDN cachovat ODPOVĚĎ na edge
Přeměna čtecích dotazů na cachovatelné GETy umožní CDN obsluhovat je na edge a zmenší payloady. Nápovědy @cacheControl (max-age, scope) umožňují serveru deklarovat TTL na úrovni pole, které CDN i serverová cache Apolla respektují.
Response cache (např. od Apolla) klíčovaná podle dotazu + proměnných + rozsahu autentizace se vyhne opětovnému spouštění resolverů; DataLoader řeší deduplikaci v rámci požadavku (jiná věc — není to cache napříč požadavky).
Návrh s jedním endpointem a POST rozbíjí naivní HTTP cachování, takže tazatelé chtějí slyšet vrstvenou odpověď: normalizovaná cache entit na klientovi, persisted queries + @cacheControl pro odemčení CDN/edge cachování a kam zapadá DataLoader (v rozsahu požadavku, ne napříč požadavky).
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět