Skip to content

Commit 936e494

Browse files
committed
added a README
1 parent 52bbb91 commit 936e494

File tree

1 file changed

+28
-0
lines changed

1 file changed

+28
-0
lines changed

README.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
# GraphQL Cache
2+
3+
### Stellate and urql like cache for your GraphQL APIs
4+
5+
## Why?
6+
7+
Because all GraphQL requests are on a single endpoint and resources are differentiated based on what your request body looks like, we can't use HTTP caching methods for them (say goodbye to etags, 304s, etc.)
8+
9+
## What does it do?
10+
11+
This package takes a GraphQL request, caches the response - if the same request is repeated again, we can serve the response directly from cache without hitting the origin server.
12+
13+
## Why can I just use a key value store to cache?
14+
15+
You can, but the challenge comes with cache invalidation. How do you identify what fields have changed or have been added so you can invalidate your cache? One way is to invalidate everything for the user - but if you have updates happening often, it becomes as good as no cache.
16+
17+
Since all requests to your GraphQL server pass through `graphql_cache` (including mutations), it can automatically invalidate objects and entire queries for which data has changed. Basically, it supports partial cache invalidation.
18+
19+
## What's the current status of this project?
20+
21+
This currently an experiment, and still a work in progress.
22+
23+
1. Automatic partial cache invalidation doesn't exist
24+
2. Query caching is tested for only the test API and not for all possible query formats/types.
25+
3. Limited to one operation per request.
26+
4. More limitations that I can't even think of now.
27+
28+
Once the project is feature complete, it will be open sourced. Once it is ready enough to handle hobby project workloads, it will be open sourced as a complete package.

0 commit comments

Comments
 (0)