> For the complete documentation index, see [llms.txt](https://docs.orbitgraphql.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.orbitgraphql.com/how-does-it-work.md).

# How does it work?

The cache server caches based on the `__typename` and a primary key in your response objects. `__typename` is an internal field in every GraphQL type, and I assume every unique object in your GraphQL will have a primary key that you will sending to your frontend.

When a request hits the Orbit GraphQL server, it converts it into an AST (abstract syntax tree), then appends the `__typename` field to every parent field and the query.

Using the `__typename` and `id` (*primary key - configurable*) fields in your response it builds a cache for the returned objects.

On subsequent requests, if the same `query` is made again with the same `variables`, and the result exists in the cache, Orbit builds the response object itself and sends that to your client.

For every `mutation` that hits the Orbit server, it forwards the request to the origin to make the mutation, and then checks the `__typename` and `id` fields returned by the mutation. Based on the response that is received, we know which object was updated and use it to invalidate the cache accordingly.

You can also invalidate the cache manually using the cache purging APIs.

This is not production ready yet.

Here is a non-exhaustive list of things planned for the project:

1. Support for Fragments.
2. Benchmarking.
3. Go/JavaScript clients for the administration APIs (used to flush cache).
4. Better observability setup (to help monitor how the cache server is performing).
5. Support for analytics on top of your GraphQL API to help you get insights on how your API is being consumed.

Currently, there's no plan to offer a hosted version for this (I'm scratching my own itch but, never say never)