Migrating from Next
thinking about migrating a project from next over my new year break, got a few questions:
1. is there an equivalent for
unstable_cache, "use cache" or fetch() caching? currently these use the vercel data cache, so i'd like to continue this without needing a separate redis instance.
i have four usages:
a) database req: not critical, revalidates every 15 minutes
b) fetch req: not critical, revalidates every 5 minutes
c) fetch req: not critical, revalidates every 24 hours
d) fetch req: critical, revalidates every 12 hours
for a, b & c, i could turn these into server functions with cache control headers, then run them on the client via useQuery, but then that would introduce a waterfall
my understanding is that if i ran these on the server in a loader, the cache control headers wouldn't do anything as it just executes as a normal async function?
2. currently using the experimental next streaming and dehydration package. start just handles this use case out of the box right?
3. currently using nuqs (https://github.com/47ng/nuqs) to prevent RSC round trips upon search param change. my understanding of TSR is that i wouldn't need this anymore as it actually has sane search params management?
4. currently on react 19 and using the compiler, are these supported at all?20 Replies
flat-fuchsia•9mo ago
2) I think so, yes
3) yes, you don't need this anymore.
4) react 19 yes, compiler has been tested, but not extensively. seemed to just work
magic-amber•9mo ago
I would also like some insight on 1) if possible. I'm coming from Nuxt and know there's https://nitro.build/guide/cache, but I couldn't find the same functions in TS Start's API routes docs (it seems to only export h3 functions not the Nitro functions). I would also be interested in support for Vercel Data Cache (although from what I can see through other frameworks seems like Vercel isn't providing a public API for this atm?)
flat-fuchsia•9mo ago
@Tanner Linsley has been working on this here: https://github.com/TanStack/router/pull/2926
GitHub
feat: static build caching for server functions by tannerlinsley · ...
This adds a new concept of "server function type". By default, all server functions are dynamic, meaning they will reach out to the server to execute. This addition brings a new t...
magic-amber•9mo ago
So it will only be static caching for now? Since @Kairu (and likely many others) are looking for runtime revalidation/swr
harsh-harlequinOP•9mo ago
there doesn’t appear to be any non-next implementations (that I can find) for the vercel data cache, so it’s looking like a separate redis store is gonna be necessary
absent-sapphire•9mo ago
You mean ISR?
You can already do that today with cache headers
absent-sapphire•9mo ago
You can swr server functions https://github.com/TanStack/tanstack.com/blob/556d848e885829f875e64e7b243ba95d566d0dc7/app/routes/_libraries/blog.%24.tsx#L33
GitHub
tanstack.com/app/routes/_libraries/blog.$.tsx at 556d848e885829f875...
The marketing and docs site for all TanStack projects - TanStack/tanstack.com
absent-sapphire•9mo ago
Or entire html responses
absent-sapphire•9mo ago
GitHub
tanstack.com/app/routes/$libraryId/$version.docs.$.tsx at 556d848e8...
The marketing and docs site for all TanStack projects - TanStack/tanstack.com
magic-amber•9mo ago
I think the only thing that's "missing" then for Kairu's (and possibly myself's) use case is just the ability to cache
fetch calls to third party APIs (or the more general case, calls to arbitrary JS functions like https://nextjs.org/docs/app/api-reference/functions/unstable_cache). I saw in #start TS Start might move to using Nitro directly soon, which means this problem might go away indirectly since Nitro already has something for caching arbitrary JS functions (defineCachedFunction).
The only leftover feature from Kairu's original post would be supporting Vercel Data Cache as a cache handler, but I think Vercel is keeping Data Cache exclusive to Next atmabsent-sapphire•9mo ago
Yep
You could use unstorage with nitro
They have function caching that works basically everywhere you can hook up an unstorage adapter
harsh-harlequinOP•9mo ago
my main thing is trying to make the most of the vercel data cache rather than relying on a separate storage layer
say i have two pages:
layout) functions a & b are inherently required as they're part of the shell
page 1) requires functions c & d
page 2) requires function c
on first load, page 1's loader runs on the server, so all four functions will make api/db queries as there's no caching
then i navigate to page 2, no loading is necessary as function c has been loaded into the queryClient
if i reverse the navigation order (page 2 -> page 1), function d will load from the cdn because it's wrapped in a server function with cache control headers
the sticking point seems to be that vercel doesn't provide a way for other frameworks to manipulate their data cache
absent-sapphire•9mo ago
Yep
And honestly, server-side caching is a bit riskier and harder to integrate well into a meta framework
Unless.. you own the host
Which explains why they do what they do
I personally would rather approach it like this:
- If I need really granular caching, I'll use Query on the client, avoiding requests to the server altogether if possible
- If I can cache at the request level, I will use cache headers on API request and/or HTML responses
- If there's truly a high traffic server-side hot path that can benefit from caching, I'll opt for a more durable/transparent server-side cache like the ones unstorage wraps over.
harsh-harlequinOP•9mo ago
gotcha, thanks. i think for the non-critical ones i'll just run on the client with cache headers, then run a redis instance for the critical one. not the end of the world, at least i can replicate vercel's on-deploy cache flushing by making the commit hash as part of the cache key
absent-sapphire•9mo ago
Sweet!
harsh-harlequinOP•9mo ago
am i missing something here? using the same approach nekochan's repo is using to ensure critical info is available, but it runs 3 times on first load, then still runs the server function on subsequent client navigations despite being placed into the query cache already
harsh-harlequinOP•9mo ago
kinda assumed it would only run once on first load, then pull from query cache on next navigation
flat-fuchsia•9mo ago
you need to use the query integration as shown here:
https://github.com/TanStack/router/blob/main/examples%2Freact%2Fstart-basic-react-query%2Fapp%2Frouter.tsx
GitHub
router/examples/react/start-basic-react-query/app/router.tsx at mai...
🤖 Fully typesafe Router for React (and friends) w/ built-in caching, 1st class search-param APIs, client-side cache integration and isomorphic rendering. - TanStack/router
harsh-harlequinOP•9mo ago
using nekochan’s boilerplate so it’s already setup, everything looks correct to me
harsh-harlequinOP•9mo ago
okay so for whatever reason, the root loader is triggering twice on /favicon.ico, which is what's resulting in three executions on first load, then triggering again for /favicon.ico on every navigation
repro: https://github.com/kylekz/tss