Hard time to truly understand Server Side Rendering
Answered
Atlantic herring posted this in #help-forum
Atlantic herringOP
I just want to know, did Vercel come up with SSR or has it been around longer? I’m kinda confused because I thought it’s been a thing for like 5–7 years already or longer.
Answered by Roseate Spoonbill
Definitely deep enough for you to understand how it works. Probably not deep enough to understand how everything is implemented, but I'd say that's not required (unless for some reason you need to know implementation details of the entire framework), and still plenty enough for you to get started. They also have an introduction to next architecture (mainly compiler), which explains some under the hood stuff a little bit, but not down to implementation: https://nextjs.org/docs/architecture. I'd also recommend all of the articles in Getting Started section. There's plenty to choose from when it comes to other learning sources.
What I usually do is read how feature can be used (e.g. data caching) in docs and if I still need more, I'd look for usage examples. E.g. I personally like looking at Theo's materials on given subject if there is any (https://www.youtube.com/@t3dotgg). Finally, if you need understanding of how any given feature is implemented, you can ask about it here, on help forums. Many users, including myself, have already stepped into Next source code and may be able to explain some features.
The thing is there is plenty intricacies about Next depending on which output you use (
So I'd suggest starting on the resources I mentioned above. If you need more, you'll need to ask a bit more targeted questions. E.g. "How fetch data caching works" or "When will users get new content after cache revalidation".
What I usually do is read how feature can be used (e.g. data caching) in docs and if I still need more, I'd look for usage examples. E.g. I personally like looking at Theo's materials on given subject if there is any (https://www.youtube.com/@t3dotgg). Finally, if you need understanding of how any given feature is implemented, you can ask about it here, on help forums. Many users, including myself, have already stepped into Next source code and may be able to explain some features.
The thing is there is plenty intricacies about Next depending on which output you use (
standalone which includes backend server, or export which is usually used for SPA), what type is given page (static, dynamic, or semi dynamic when using new dynamicIO) and which runtime you are building for. Each of those will influence how the page will work after the build and if it can be rebuilt/refreshed. Jumping straight under the hood will make it much harder to understand those dependencies if you don't have a good understanding of how and when to use those features. So I'd suggest starting on the resources I mentioned above. If you need more, you'll need to ask a bit more targeted questions. E.g. "How fetch data caching works" or "When will users get new content after cache revalidation".
26 Replies
Dutch
20 years at least 😂
since xampp
even react invented to fix this "long server loading times" problem
Atlantic herringOP
yeah that’s my problem 😂
I see all these posts everywhere talking about SSR and whether they should use it or not, but I always thought this concept has existed forever or at least as long as I can remember
I see all these posts everywhere talking about SSR and whether they should use it or not, but I always thought this concept has existed forever or at least as long as I can remember
Dutch
actually its more deep than you think, but cuz of here is next server i cant say bad things about this
basically there is a problem you shouldnt even try to solve it
@Dutch basically there is a problem you shouldnt even try to solve it
Atlantic herringOP
like with SSR or what exactly do you mean?
Dutch
HTTP
@Dutch HTTP
Atlantic herringOP
do you mean like coz HTTP is a stateless protocol, etc. ?
@Atlantic herring do you mean like coz HTTP is a stateless protocol, etc. ?
Dutch
i mean you should wait for response comes from that server
even if you render on server or client
Roseate Spoonbill
Couple things worth mentioning:
- SSR as a "rendering sites on the server" is like 30 years old
- SSR as a term is relatively new - people started using it more widely 5-10 years ago.
- SSR as it is in Next is something entirely unique and inventive - the caching layers and mechanism they've built, especially the new ones that are in the canary, is something that not many frameworks can pull of. With ppr around the corner and use cache, SSR becomes much more than just "creating html on the server"
- SSR as a "rendering sites on the server" is like 30 years old
- SSR as a term is relatively new - people started using it more widely 5-10 years ago.
- SSR as it is in Next is something entirely unique and inventive - the caching layers and mechanism they've built, especially the new ones that are in the canary, is something that not many frameworks can pull of. With ppr around the corner and use cache, SSR becomes much more than just "creating html on the server"
@Roseate Spoonbill Couple things worth mentioning:
- SSR as a "rendering sites on the server" is like 30 years old
- SSR as a term is relatively new - people started using it more widely 5-10 years ago.
- SSR as it is in Next is something entirely unique and inventive - the caching layers and mechanism they've built, especially the new ones that are in the canary, is something that not many frameworks can pull of. With ppr around the corner and use cache, SSR becomes much more than just "creating html on the server"
Atlantic herringOP
Great. Where can I learn more about this?
Roseate Spoonbill
Depends on which part you are interested in. Personally, I prefer to start new project and play around with it. Next has its own tutorial which will give you the basics. After that docs. Relatively new mechanisms (present in Next 15, or only in canary release) are well covered on the YouTube as long as we talk about videos that are couple of months old. If you need more specific info, ask questions on this forum. Sorry I don't have any specific links, but I'm traveling at the moment and on the phone. If you tell me more specifically what you prefer as a form of education and which things you are more interested in, I can try pointing you to specific sites. As it stands you asked very generic question and I'm not even sure what you want to learn more about.
@Roseate Spoonbill Depends on which part you are interested in. Personally, I prefer to start new project and play around with it. Next has its own tutorial which will give you the basics. After that docs. Relatively new mechanisms (present in Next 15, or only in canary release) are well covered on the YouTube as long as we talk about videos that are couple of months old. If you need more specific info, ask questions on this forum. Sorry I don't have any specific links, but I'm traveling at the moment and on the phone. If you tell me more specifically what you prefer as a form of education and which things you are more interested in, I can try pointing you to specific sites. As it stands you asked very generic question and I'm not even sure what you want to learn more about.
Atlantic herringOP
Alright, I’m just trying to learn more about how Next works under the hood in general. I usually prefer docs and YouTube videos.
Would you say the Next docs go deep enough to really get into that kind of stuff?
Would you say the Next docs go deep enough to really get into that kind of stuff?
Roseate Spoonbill
Definitely deep enough for you to understand how it works. Probably not deep enough to understand how everything is implemented, but I'd say that's not required (unless for some reason you need to know implementation details of the entire framework), and still plenty enough for you to get started. They also have an introduction to next architecture (mainly compiler), which explains some under the hood stuff a little bit, but not down to implementation: https://nextjs.org/docs/architecture. I'd also recommend all of the articles in Getting Started section. There's plenty to choose from when it comes to other learning sources.
What I usually do is read how feature can be used (e.g. data caching) in docs and if I still need more, I'd look for usage examples. E.g. I personally like looking at Theo's materials on given subject if there is any (https://www.youtube.com/@t3dotgg). Finally, if you need understanding of how any given feature is implemented, you can ask about it here, on help forums. Many users, including myself, have already stepped into Next source code and may be able to explain some features.
The thing is there is plenty intricacies about Next depending on which output you use (
So I'd suggest starting on the resources I mentioned above. If you need more, you'll need to ask a bit more targeted questions. E.g. "How fetch data caching works" or "When will users get new content after cache revalidation".
What I usually do is read how feature can be used (e.g. data caching) in docs and if I still need more, I'd look for usage examples. E.g. I personally like looking at Theo's materials on given subject if there is any (https://www.youtube.com/@t3dotgg). Finally, if you need understanding of how any given feature is implemented, you can ask about it here, on help forums. Many users, including myself, have already stepped into Next source code and may be able to explain some features.
The thing is there is plenty intricacies about Next depending on which output you use (
standalone which includes backend server, or export which is usually used for SPA), what type is given page (static, dynamic, or semi dynamic when using new dynamicIO) and which runtime you are building for. Each of those will influence how the page will work after the build and if it can be rebuilt/refreshed. Jumping straight under the hood will make it much harder to understand those dependencies if you don't have a good understanding of how and when to use those features. So I'd suggest starting on the resources I mentioned above. If you need more, you'll need to ask a bit more targeted questions. E.g. "How fetch data caching works" or "When will users get new content after cache revalidation".
Answer
@Roseate Spoonbill Definitely deep enough for you to understand how it works. Probably not deep enough to understand how everything is implemented, but I'd say that's not required (unless for some reason you need to know implementation details of the entire framework), and still plenty enough for you to get started. They also have an introduction to next architecture (mainly compiler), which explains some under the hood stuff a little bit, but not down to implementation: https://nextjs.org/docs/architecture. I'd also recommend all of the articles in Getting Started section. There's plenty to choose from when it comes to other learning sources.
What I usually do is read how feature can be used (e.g. data caching) in docs and if I still need more, I'd look for usage examples. E.g. I personally like looking at Theo's materials on given subject if there is any (https://www.youtube.com/@t3dotgg). Finally, if you need understanding of how any given feature is implemented, you can ask about it here, on help forums. Many users, including myself, have already stepped into Next source code and may be able to explain some features.
The thing is there is plenty intricacies about Next depending on which output you use (`standalone` which includes backend server, or `export` which is usually used for SPA), what type is given page (`static`, `dynamic`, or semi dynamic when using new `dynamicIO`) and which runtime you are building for. Each of those will influence how the page will work after the build and if it can be rebuilt/refreshed. Jumping straight under the hood will make it much harder to understand those dependencies if you don't have a good understanding of how and when to use those features.
So I'd suggest starting on the resources I mentioned above. If you need more, you'll need to ask a bit more targeted questions. E.g. "How fetch data caching works" or "When will users get new content after cache revalidation".
Atlantic herringOP
Thanks for all the valuable informations! This helps a lot!
I have a kind of off-topic question. I decided to start build my first real web app using Firebase (Firebase Authentication, Firebase Firestore, Firebase Storage).
Of course, I want to make my web app highly performany and secure. The only publicly available routes should be
I terms of performance, I want the web app to be fast with no long page loads, loading spinners, skeletons, etc.
I don’t know how familiar you are with Firebase, but Firebase basically has a Client SDK (which only runs on the client side) and an Admin SDK that should only run in a privileged environment/server.
Would you say it’s possible to have a fast and performant (no long loading spinners, etc.) and secure (protected routes) app using only the client side?
I have a kind of off-topic question. I decided to start build my first real web app using Firebase (Firebase Authentication, Firebase Firestore, Firebase Storage).
Of course, I want to make my web app highly performany and secure. The only publicly available routes should be
/login , /sign-up and /reset-password. All other routes should be protected by authentication, meaning a user must be authenticated to access them.I terms of performance, I want the web app to be fast with no long page loads, loading spinners, skeletons, etc.
I don’t know how familiar you are with Firebase, but Firebase basically has a Client SDK (which only runs on the client side) and an Admin SDK that should only run in a privileged environment/server.
Would you say it’s possible to have a fast and performant (no long loading spinners, etc.) and secure (protected routes) app using only the client side?
Atlantic herringOP
Could it make sense to just render the page shell, layout, skeleton and any non-user-specific content (no user data) on the server, then pass that down to the client to avoid needing the Firebase Admin SDK?
Basically, I’m just trying to figure out if I actually need the Admin SDK, or if it’s just overkill
Basically, I’m just trying to figure out if I actually need the Admin SDK, or if it’s just overkill
Roseate Spoonbill
I'd say that's something you should ask entirely in separate topic, but to answer shortly, I think you can do it definitely with client SDK if you configure security well. Bear in mind, though, that in such case you are exposing your connection details to clients, while using pure Admin SDK you are not. It's not a problem, but you do have to put extra work into policies in Firebase, to make sure users can only change what they are allowed to.
Also if you want to use real-time features of firebase, you'll have to use Client SDK on browser end anyway.
Just make sure that if you use Admin SDK, you should protect those files with
Also if you want to use real-time features of firebase, you'll have to use Client SDK on browser end anyway.
Just make sure that if you use Admin SDK, you should protect those files with
import "server-only" to be extra sure, that none of admin credentials will be exported with client code.@Roseate Spoonbill I'd say that's something you should ask entirely in separate topic, but to answer shortly, I think you can do it definitely with client SDK if you configure security well. Bear in mind, though, that in such case you are exposing your connection details to clients, while using pure Admin SDK you are not. It's not a problem, but you do have to put extra work into policies in Firebase, to make sure users can only change what they are allowed to.
Also if you want to use real-time features of firebase, you'll have to use Client SDK on browser end anyway.
Just make sure that if you use Admin SDK, you should protect those files with `import "server-only"` to be extra sure, that none of admin credentials will be exported with client code.
Atlantic herringOP
Thanks, I really appreciate it! I’ll get on it!
Just one last question, how would you go about securing all routes except /login, /sign-up, and /reset-password, so that anyone trying to access a protected route without being authorized sees an “Unauthorized” page? Is that even possible using just the client SDK or on client side in general?
Just one last question, how would you go about securing all routes except /login, /sign-up, and /reset-password, so that anyone trying to access a protected route without being authorized sees an “Unauthorized” page? Is that even possible using just the client SDK or on client side in general?
Roseate Spoonbill
Server side is easy - you add auth check on pages that need to be secured before page is rendered. That's usually what I go for.
Client side is bit less intuitive - on client you don't use auth to protect routes. You use auth to protect user from seeing unauthorized errors all over the place. So on client use auth checks, but remember, that they don't protect your app or api, those are for your users. You and your app is only protected by server checks. Be it firebase, or next.js backend. And on client you should still do this check on pages - check if user is logged in, if not, redirect him to "unprotected" page (again - quotation deliberate, as client-side page isn't really protected, it's just so that user won't suffer from seeing broken UI when data won't load).
Client side is bit less intuitive - on client you don't use auth to protect routes. You use auth to protect user from seeing unauthorized errors all over the place. So on client use auth checks, but remember, that they don't protect your app or api, those are for your users. You and your app is only protected by server checks. Be it firebase, or next.js backend. And on client you should still do this check on pages - check if user is logged in, if not, redirect him to "unprotected" page (again - quotation deliberate, as client-side page isn't really protected, it's just so that user won't suffer from seeing broken UI when data won't load).
But please, bofore you ask more followup questions, please consider marking this thread as solved, and asking those questions in separate threads 😉 It helps moderating the discussions. And it will open your question to be answered by more experienced users. People rarely engage in discussion that has longer threads, as they assume that someone else has bigger context. And while I am happy to help, I'm sure you'll benefit more from getting answers from more people.
Atlantic herringOP
Thanks, I appreciate it!
Varied Thrush
@Atlantic herring good read to understand React & Next on server: https://vercel.com/blog/understanding-react-server-components
+ good visual (only the end is PPR specific): https://www.youtube.com/watch?v=MTcPrTIBkpA
+ good visual (only the end is PPR specific): https://www.youtube.com/watch?v=MTcPrTIBkpA