I know exactly what you're talking about, I have these waterfalls all over my project, I think especially on its most important page. Here, by invoking loadPremiumArticles, you tell the server to not wait for confirmation on the user's premium status to start fetching on the server, you do the articles fetching at the same time on the server no matter what, knowing that if the user is free the articles will not be sent to the client anyways. In this case (I'm at 7:05) the articles are static so by default in Next.js they would have been cached, but if they were dynamic... Would the waterfall still be avoided? I'm rambling but I think it would if all the functions called would make their own entire calls themselves, have them cached with cache(), and that it would even be more secured because instead of passing an ID as a prop to launch another function to load a user's data on a dashboard, each data, each RSC component would do its own entire fetching meaning if someone in some way could pass a stolen ID to the component as a prop it wouldn't work... Sorry I'm going everywhere with this, I just hope my comment is not too convoluted. 😬
I really appreciate this content about the features that come with app router, still can't understand when and where to use server actions vs route handlers, hopefully you soon find time to share the best practices. Thank you for this content!
Amazing. I am your new subscriber, just one question will it affect on data change coming different from already cached data then will we get new or the cached one?
Thank you! And great question! The cache() function from React uses a very short lived cache that's only kept for the lifecycle of the current request. So if data changes and you reload the page you'll still see the new data. Check out this video that has some more details on how cache works: th-cam.com/video/MxjCLqdk4G4/w-d-xo.html
This is a good example of a scenario where cross-request caching could work well - I think it would be great if the `cache` function had some TTL options. In the meantime, assuming we're not/we can't use next's fetch cache, what's the best alternative for caching data that isn't request specific?
Yup! Great point, a long lived cross request cache for premium articles would be awesome. I think the best caching solution would be one that has low latency between the cache server and server component. If the latency is low enough then I think you can give Redis or Memcache a try. I've even heard of some people using Postgres or the file system for caching in their server apps. Personally, I tend to reach for Redis first, but no specific reason... I'm just familiar with it.
Great content, thanks for both videos. It feels very unnatural/hacky to call the async function, though can 100% see the benefits. Something to think about for sure
Glad you enjoyed the video and thanks for commenting! Yes, I totally agree on it being unnatural. I also feel the same away about Promise.all() data fetching as well. It's possible to take it too far and over-optimize by calling the preload functions everywhere. It's a useful tool to know about, but it doesn't need to be used on every page.
You and Sam are creating the best content about RSC by such a huge margin I can’t even describe.
Oh wow that's so great to hear! Thank you
I know exactly what you're talking about, I have these waterfalls all over my project, I think especially on its most important page. Here, by invoking loadPremiumArticles, you tell the server to not wait for confirmation on the user's premium status to start fetching on the server, you do the articles fetching at the same time on the server no matter what, knowing that if the user is free the articles will not be sent to the client anyways.
In this case (I'm at 7:05) the articles are static so by default in Next.js they would have been cached, but if they were dynamic... Would the waterfall still be avoided?
I'm rambling but I think it would if all the functions called would make their own entire calls themselves, have them cached with cache(), and that it would even be more secured because instead of passing an ID as a prop to launch another function to load a user's data on a dashboard, each data, each RSC component would do its own entire fetching meaning if someone in some way could pass a stolen ID to the component as a prop it wouldn't work... Sorry I'm going everywhere with this, I just hope my comment is not too convoluted. 😬
Just got introduced to this channel, the content is amazing.
Thank you!
I really appreciate this content about the features that come with app router, still can't understand when and where to use server actions vs route handlers, hopefully you soon find time to share the best practices. Thank you for this content!
preloading restricted data in RSC makes sense as its not visible in any way to the end user. good video
Thanks!
❤ done watching
Thanks!
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
Amazing. I am your new subscriber, just one question will it affect on data change coming different from already cached data then will we get new or the cached one?
Thank you! And great question! The cache() function from React uses a very short lived cache that's only kept for the lifecycle of the current request. So if data changes and you reload the page you'll still see the new data. Check out this video that has some more details on how cache works: th-cam.com/video/MxjCLqdk4G4/w-d-xo.html
This is a good example of a scenario where cross-request caching could work well - I think it would be great if the `cache` function had some TTL options. In the meantime, assuming we're not/we can't use next's fetch cache, what's the best alternative for caching data that isn't request specific?
Yup! Great point, a long lived cross request cache for premium articles would be awesome.
I think the best caching solution would be one that has low latency between the cache server and server component. If the latency is low enough then I think you can give Redis or Memcache a try. I've even heard of some people using Postgres or the file system for caching in their server apps.
Personally, I tend to reach for Redis first, but no specific reason... I'm just familiar with it.
Great content, thanks for both videos. It feels very unnatural/hacky to call the async function, though can 100% see the benefits. Something to think about for sure
Glad you enjoyed the video and thanks for commenting!
Yes, I totally agree on it being unnatural. I also feel the same away about Promise.all() data fetching as well.
It's possible to take it too far and over-optimize by calling the preload functions everywhere. It's a useful tool to know about, but it doesn't need to be used on every page.