Caching in Apollo Kotlin
Introduction
Apollo Kotlin supports multiple forms of client-side caching for different purposes. Its built-in normalized caches are especially useful for storing GraphQL operation results in an efficient, deduplicated way.
Additionally, Apollo Kotlin supports server-side caching of operation strings via persisted queries.
Here's a summary of all supported caches:
| Cache | Description |
|---|---|
| Built-in normalized caches | Deduplicates GraphQL response data, enabling your app to use it as a source of truth for your UI. Can also dynamically react to changes in that data. Both in-memory and SQLite caches are included, and you can use both to combine in-memory speed with SQLite persistence. |
| Built-in HTTP cache | Caches response data at the HTTP level. Can be faster to get started with and uses less CPU than normalized caches, but duplicates data and can't act as a source of truth. |
| External caches | If you're already using an external cache (such as Room or SQLDelight), you can use it with Apollo Kotlin. Instead of using Apollo for both the network and database domains, you use generated models for the network and map them to your own database models. |
| Persisted queries (APQ) | With APQ, your client sends a hash of most queries to the server instead of the query itself. This makes requests much smaller and enables the use of GET requests instead of POST. This in turn makes it possible to cache results at the CDN level. The server also caches your query strings, meaning it doesn't have to parse a particular query each time it's sent. Persisted queries can be automatic persisted queries (which require little configuration), or you can use custom persisted query IDs. |
Client-side and server-side caches are not mutually exclusive, and most full-stack applications use both. Using a normalized cache with persisted queries helps you minimize your number of network requests, while also taking advantage of a CDN for requests that are required.