Using tanstack query for caching in rest APIs

[RobinVdBroeck]

Hello,

I wonder if anyone ever used a tanstack query like system for caching (but mostly cache invalidation) in rest apis.

Let's say I've got a simple crud system:

GET /v1/resource/:id
DELETE /v1/resource/:id
POST /v1/resource

The implementing code could than look somelike - in psuedocode:

const queryclient = await createQueryClientWithRedisBackend();

router.get("/v1/resource/:id", ({ id }) => {
   const { data } = await queryclient.useQuery({
      queryKey: ["resource", id],
      queryFn: () => getFromDatabase(id),
   })
});

router.post("/v1/resource", ({ payload }) => {
  const id = await createInDb(payload);
  await queryClient.setQueryData(["resource", id], payload);
});

router.delete("/v1/resource/:id", ({ id }) => {
   await deleteFromDb(id);
   await queryClient.removeQueries({
       queryKey: ["resource", id]
   })
});

Does this have any gotchas I should be aware of?

[TkDodo]

you can’t useQuery on the server, it would need to be queryClient.fetchQuery

[RobinVdBroeck]

I'm just wondering if this is a good idea from an architectural view, not looking for specific details.

I'm mainly wanting to this make it easier to invalidate redis/memcached/... keys, which can be a pain. I'm familiar with react query for frontend applications, and I wonder if I could also use the library for my backend development.

However, I'm afraid tanstack query has given me a hammer and now I see nails everywhere, while I really need a saw.

[TkDodo]

You can definitely use react-query for caching on the server, but note that it doesn’t persist per anywhere default (it’s in memory only), so it doesn’t really compare with redis. It’s also not distributed and probably not optimized specifically for this use-case.

What you can do is combine a QueryClient with persistence and a server storage solution like redis:

1. when a request comes in, create a new, request-scoped QueryClient
2. put data into the cache with dehydrate by reading from e.g. redis
3. perform actions you want
4. when the request ends, serialize the client with hydrate and write it to redis.

then, when the next request comes in, it will restore from redis and you’d basically have a filled cache. You can also decide to only restore parts of the cache you’re interested in.

I think this is a valid combination - you can use the QueryClient for in-memory caching (where it’s good at) and combine it with a different solution for persistence & distribution.

But I’ve also used cachified on the server, which is a good alternative that also plugs into arbitrary storages.