Is Tanstack Query needed when using Next Route Handlers?
Basically what it says. To my understanding a Route Handler is basically a custom built endpoint that receives a
Request and returns a Response. Standard REST-ful stuff really.
With that in mind, if I'm fetching data on the client, would something like Tanstack Query still be relevant / provided any significant value? I know the Route Handlers already include caching and revalidation, as does TQ, but I'm not sure if TQ provides anything further that makes it worth including.
Given the versatile nature of TQ and the sheer number of features, I imagine so, but wanted to check they weren't already covered by Next.Routing: Route Handlers | Next.js
Create custom request handlers for a given route using the Web's Request and Response APIs.
6 Replies
Next Route and Tanstack Query are different things
NextRoute creates api endpoints for you
TanstackQuery handles async state + caching + deduping and more on client side
you can use TSQuery to call api routes, but outside of that, not that much difference
That's kind of my question. Is wrapping calls to my Route Handlers in TQ queries kind of pointless, given that the Route Handlers already have caching, revalidation etc. built in (or opt-in), or is there enough additional value in the TQ queries to make it worth it?
TQ in general handles all kinds of async state
TSQ caching is good enough
APIRoutes caching is a shitshow that isnt worth
unless you know what you are doing, caching api responses is quite bad because of stale data
Presuming I have Route Handlers (which I think are App Router versions of API Routes), I should probably wrap them in TQ then?
it's a good thing
react async handling is awful
Alright, makes sense. Thanks for the help.