Question about the demo
📣 For those who haven't heard, we're working on a major integration and partnership with the TanStack project and TanStack Start in particular. We're super excited about what the combo of TanStack + Convex will enable.
We'll have more details soon, but check out a bit of a preview here: https://twitter.com/convex_dev/status/1816637195459133787
If you have any early questions, fire away. The team is working on this very very actively right now.
8 Replies
I like that demo with the incrementing message count. Would that functionality be possible with Next.js? I am guessing it’s really easy to make a hydration error trying to build something like that
Probably a good question for @ballingt on the specifics of what we're able to do here that are harder or impossible with Next.js
Ok, not an urgent question. First impression of the demo blew my mind. Had to watch it many times
Congrats, it’s going to open up many use cases
Yeah, there's more layers to this here, especially when it comes to the integration with the tanstack router and the fact that tanstack query's caching automatically does all the tricks I worked on here ( https://www.youtube.com/watch?v=ZgxDlSUGpfE ) without any new code from us
Convex
YouTube
Can your database do this? Ep. 1: Magic caching
A Next.js app with no query cache? Jank. One with a cache? No more jank, but now we need to deal with cache invalidation and application consistency. Ugh.
But with Convex's magic query cache, Convex's powerful subscriptions are cached, not merely values. So you get the best of both words.
Repository here:
https://github.com/jamwt/cached-dmv
...
and this isn't requiring the use of duplicating your fetch dependencies in a central loader
this is all using component-local queries
You can definitely server-render with Next.js! The issue (the simple version of which is demonstrated in the video) is if these are separate queries then when they're fetched they may be fetched at points in time.
When the queries are right next to each other like this the better solution is to combine them into one query, but sometimes you end up with multiple pieces of data you're trying to assemble and they actually come from different logical timestamps and that's a problem: say you load a list of users at 1:03pm but you load the list of messages at 1:05pm and in between a new user joined and posted a message: you'll have a message with a user ID that doesn't exist on the client, and that could cause a bug.
This is a normal web dev problem that Convex solves for you with consistent client views! ...except for during a server-side render, when separate http requests are sent for each query. The solution demonstrated here is using the same server timestamp for both queries.
Awesome news! any idea when Tanstack Start is being released?
@Jacob Kim soon I hope! It sounds like it's a "when it's done, it's done" situation, but trying it out it feels close to alpha.