Centralised API definitions, Cache key ergonomics and Tanstack DB

[VaZark]

I'm evaluating TanStack Query for my next project, and I wish to fully adopt the TanStack ecosystem as I like the headless utility philosophy of the project. Is it possible to create a centralised API definition, similar to RTKQuery?

What I like about RTKQuery: It separates the invocation and the query definitions. The queries are all colocated, and with the help of the invalidateTags property, we can identify the queries that might be refetched at a glance.

The issue with Tanstack style: As it stands, I get the impression that it would be easy to miss the cache keys for invalidation, and we might have to run touch different files whenever updating the keys?

Is this where TanStack DB comes in? Can I leverage the DB project's Query Collection to perform API calls in the background and invoke a mutation to invalidate them?

[ismaildasci]

hey, been using both RTK Query and TanStack Query in production - here is my take:

for centralised API definitions, you can absolutely do this with TanStack Query. create a queries folder and export factory functions:

const userQueries = {
all: () => ["users"],
lists: () => [...userQueries.all(), "list"],
list: (filters) => [...userQueries.lists(), filters],
details: () => [...userQueries.all(), "detail"],
detail: (id) => [...userQueries.details(), id]
}

then your invalidation becomes super predictable - invalidate userQueries.all() and everything user-related refetches. no need to hunt through files.

for the missing cache keys problem - thats actually a feature imo. RTK Query hides invalidation complexity behind tags, but you end up debugging why something isnt refetching. with tanstack, the key hierarchy is explicit.

create a queryKeys.ts file that exports all your key factories. any mutation that touches users just calls queryClient.invalidateQueries({ queryKey: userQueries.all() }). done.

TanStack DB is overkill for this use case. its meant for local-first sync patterns not just cache management.

one pattern that works well - colocate your mutations with queries in the same file. so users.ts has both useUsers query and useCreateUser mutation. invalidation logic stays next to the data it affects.