When to use SSG,SSR,CSR, ISR, RSC More specifically
Answered
codecret posted this in #help-forum
codecretOP
I'm new to Next.js where I only use react-query to fetch data in React. I have a question about structuring my e-commerce app:
I wanna rebuild an e-commerce app that includes:
A landing page
Authentication
Products page
View single product
Add, edit, delete products from admin panel
Add, remove products from customer side
Analytics in the admin dashboard related to products and users
Am I going to combine several nextjs techniques here? Will I use different ways to fetch data in different pages?
I want to use MongoDB and I think I can use Mongoose and route handlers to create my API endpoints. However, the problem I face is how to fetch everything efficiently.
I wanna rebuild an e-commerce app that includes:
A landing page
Authentication
Products page
View single product
Add, edit, delete products from admin panel
Add, remove products from customer side
Analytics in the admin dashboard related to products and users
Am I going to combine several nextjs techniques here? Will I use different ways to fetch data in different pages?
I want to use MongoDB and I think I can use Mongoose and route handlers to create my API endpoints. However, the problem I face is how to fetch everything efficiently.
Answered by Arinji
ok so heres what i would do
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
33 Replies
ok so heres what i would do
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
Answer
CSR is used if its something you cant do on the server, i would use it very rarely.. dont keep it as a thing you can always use. The less stuff you dump onn your client, the better
codecretOP
thx!
@Arinji ok so heres what i would do
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
codecretOP
what if it doesn't contain products ? should i use ssr?
@codecret what if it doesn't contain products ? should i use ssr?
Ssr is only good for like stuff which updates daily
Or like a lot
If it updates like weekly, go with ssg
Sinhala Hound
Are you using pages router or app router?
SSG, SSR, ISR - these are terms that apply to pages router
Personally, unless you are using something which requires query params, then I'd just use ISR with appropriate revalidate lengths for everything
In cases where you do need to use query params, then use must use SSR
In app router, the story is more complicated (probably too complicated)
In app router, RSC takes over for getStaticProps/getServerSideProps - but also does some or all HTML rendering on the server, instead of on the client
In app router, the primary caching target for next.js changed from caching output (HTML) to caching fetch requests (data). So the revalidate setting would apply there (in your fetch requests, or in your mongoose queries), instead of in your output (though it is still possible to cache that, it's more tricky, and uses the complicated "side-effects" detection of various next.js apis, like
headers() and cookies()).So if you are using app router, I'd apply the same caching strategy, but to fetch requests, rather than output, at least to start.
Get your mongoose queries caches using some reasonable revalidate (ttl) setting. Then focus on doing the same for HTML output.
The single page.tsx output would generally be cached in the app router version of ISR, as long as you don't use the magic functions that opt you in to "dynamic" rendering. For the product routes (the ones with route params) you'd need to specify a
generateStaticParams function, which is similar to pages router's getStaticPaths - this function will allow the HTML of those pages to be cached in the ISR cache.(If you provide actual slugs in from
generateStaticParams it'll also cause those pages to get generated in to the static cache - if you can get away with it, just use an empty array in there, and let it get generated to ISR instead.)@Sinhala Hound Are you using pages router or app router?
codecretOP
so the modern (recommended ) way is app router ?
thanks for responding btw
for example people are using different stratigies i just want to land on one
Sinhala Hound
Yeah, app router is the "new" way. Pages router is easier, but cannot do some things.
@Arinji ok so heres what i would do
Landing: If it has any dynamic data like a shop items.. keep it SSG with the only dynamic part have a nextjs tag to revalidate it as needed
Auth will always be dynamic, no need to make it anything other than SSR
Products page, SSG def since there will be a lot of pages with sub pages etc, and not everything will be updated daily
View single page is also an ssg thing
Admin and Customer panel, keep most of it SSR (can depend on you, if you are gonna have products you can also keep that part ssg)
Analytics will def be ISR, you can update the page daily
codecretOP
so you were talking about page router which is not the recent version right?
hence i want to use app router , i have just SSR and CSR right?
can we try re-thinking about the cases?
hence i want to use app router , i have just SSR and CSR right?
can we try re-thinking about the cases?
@codecret so you were talking about page router which is not the recent version right?
hence i want to use app router , i have just SSR and CSR right?
can we try re-thinking about the cases?
Yea most of those are pages terms
For app all you have is ssr, ssg and yea
For app all you have is ssr, ssg and yea
The rest is done by caching rules
For example in app to replicate an isr type thing, you have a page you made ssg, have a fetch call in it with a time it revalidates, and there you go..isr
Sinhala Hound
Caching is complicated in app router (maybe too complicated.) First, there are 3 different rendering context. RSC (react server components) always rendered on the server, client components, which can be rendered on the server in the first pass (same as pages router), and then client components rendered on the client.
That's 3 different rendering contexts. So what's actually cached? It depends on which functions you call during rendering - this is kind of like "magic" - where it uses side effects to opt in or out of the various caching tiers.
So what are the caching tiers? Well, you still have server caching, like in pages router. And we still have the static cache (generated at build time), and ISR, which is generated in runtime (and this distinction really urks me). On top of that, you also have the fetch cache, from within the 2 server rendering contexts (RSC and server rendered client components.) The idea is that an RSC component might always need to render - so let's cache the fetch operation instead of RSC output.
This is COMPLICATED - it's too complicated, IMHO
And it also opts in to measurably slower response times from your server when switching (usually magically) in to "dynamic" rendering of RSC.
And unlike in pages router, where it's relatively easy to understand when you've correctly gotten ISR to work, getting RSC content to properly cache a route's output (particularly if you have params, but don't want to render in the generate stage of the build operation) can be very very challenging.