Do you REALLY need SSR?

you might have heard about this framework react it's well known for being the easiest way to update and render HTML on your user's devices however that last bits key on your user's devices reacts biggest Revolution was sending a giant JavaScript bundle to your user's devices that could both render the HTML that the page starts with but also update it as things change it was truly magical writing your render logic one time and having it be the logic both for your template to fill itself out and also update before react we had a thing called templating languages and libraries and Frameworks with their own template systems and it was chaos you would write your HTML first and then you would ship JavaScript to change what the HTML did and update it after it loaded but you had separate steps for building the HTML and templates and then the JavaScript that updates them after let's say you have a page with tweets like your Twitter homepage in order to render that you first need to figure out who the user is you do that on the server when they make the request you figure out what post you should show them you do that by fetching from the database on the server you then use that data to generate some HTML instead that to the user so they can see their posts but what happens when they make a new post before Frameworks like react and before the Ajax revolution of client-side JavaScript running requests a post or a new anything you did on the web would fire a full web request and refresh the entire page generating entirely new HTML react made it easier to do all of that on client and just send Json blobs back and forth all of a sudden we didn't have to fetch new HTML every time something changed this came with a cost though the first big one is obviously the client-side performance hit because the server is not rendering HTML the user's devices now the user's device is responsible for a lot more work on top of that things like HTML metadata and tags and all the fancy things you expect robots to crawl and get when you index on Google or you post on Twitter or in Discord those preview cards are all generated based on the metadata in the HTML files so if your HTML file is basically empty minus a JavaScript tag and that JavaScript loads and does everything you lose any metadata benefits whatsoever ever and you have to build your own separate system to generate unique HTML for every page that's a mess and on top of that you have to build a full separate API to actually get the data to the client to render this on your user's device it is no coincidence something like graphql came so close to react because react normalizing client-side rendering meant that apis needed to be much more strict about what data they exposed and how the client consumes it so you can actually build things using this model react and graphql allowed us to do crazy things on users devices that we've never done before but now you need a user to have a powerful device and you need to send requests back and forth a whole bunch of times in order to actually get something on their device before SSR I would have a phone or whatever we'll use squares for client-side and circles for server side so the circle is something that runs on some other device usually something that your company owns or something like versel or AWS that actually hosts your code and processes requests so the old model the way things used to work the original MPA multi-page app is my client would make a request I'll say get thing.com please so your device makes a request to the server the server does whatever it has to do to generate thing.com so something happens in this time here where it does some work I'll say this guy here I'll use dotted arrows for this work fetching from database authenticating user generating HTML these are all the things that like the server might be doing and it's time in here if I even have to go communicate with another server somewhere else to get more stuff I actually go some other server to get more data and then come back here after and at the end of all this it sends an HTML file to the user that has all the contents on it thing.com index.html and this is the file it generated if the file is a static file that the server just has on it it can skip all that and when you say getthing.com it just hands you the static HTML file but if you want it to be dynamic in any way or different based on which user is requesting what time of day they're requesting and anything to change about the HTML you need to do that on the server with the original model because again this is important HTML is static it doesn't change if you want your HTML to change you need something like JavaScript to update the HTML so we have two options either we have an HTML file with nothing in it and then the JavaScript does everything on the user's device or we generate the HTML fully on the server and then the client updates it from there so I've shown you the latter the original model the single page app model so what happens first is you request the website and you'll almost immediately get it back might even be hitting a cache so you have it instantaneously so you immediately get thing.com HTML or index.html however this HTML has almost nothing in it it doesn't have metadata it doesn't have jack it's probably just a scaffold if even that probably a blank white page with and this is the important width head tags for JavaScript files so this loads there is now some amount of time spent processing what this got back and now it realizes it needs a Javascript file to do the rest so it requests back to your CDN so again goes back and it says okay I need thing.com main.js so get thing.com mainjs this now goes from the CDN back to the user's device so you now have this Javascript file and now that you have this Javascript file finally your browser can run it open it parse it and now by the time this is done running it realizes oh we need more data than we have right now how do we get the additional data well you get that data by contacting an API so you have a separate server we'll say this is API save this API you're hitting with the request for the actual data you need to render the page this is like the posts that we should show on your feed whatever else the current home page on Twitch those types of things it's actual data a bunch of Json blobs your API does whatever it needs to fetches from database has other services caches whatever it needs to do and then it sends back after all that a bunch of data to get back some Json or whatever else and now the client can finally show you something and the important thing to know is until this point you see nothing all of these things have to happen before anything is shown on the user's device maybe if you have your thing set up right in this window you have loading Spinners from this point we have HTML on your device but it takes a while to get there because first we have to send blank HTML then we have to get some JavaScript then we have to parse JavaScript and then we're rendering after that and after we've fetched additional API data here is where we have a real page and the client has to do three separate requests for this to happen the first request is for the HTML the second one is for the JavaScript in the third and onward request is for the actual data that you need to render the page so the client can do that rendering this can get even scarier if the API doesn't just make one request if I request something I render a component and then that component needs to request more things this can become like seven back and forth before we have the correct page and we've all seen this we went to a web page where it's blank and then a bunch of like random scaffolding and skeletons load in there's loading Spinners everywhere and those loading Spinners keep ticking out and sometimes like one will disappear but two more appear underneath and it keeps going until the whole UI render that's because we're doing all of this work on the client and we're generating each of those parts every component can be its own contained set of these calls and that's really scary if we go back here what we had before Spas took over is we had this window of nothing browser load and then after that page load we get the correct page there's no state in between here there's no control over what the loading state looks like because the browser loads how the browser loads you just get that bar on the top and then the page comes down with the correct info on it it's actually a little misleading that this is that way because there's kind of two sections here of the browser load this is probably going to be shorter than above because nothing is being generated this is a static asset and then there's the window here of whatever that HTML has in it is rendered until we get back the JavaScript so this is a blank page or whatever the HTML file has and it is shown but it's not super valuable this window is annoying but it's also important with what we're talking about soon so know that when the browser loads like the HTML and the JavaScript actually being parsed this is an annoying state but all of these middle States here didn't exist before so what is SSR I want to be clear a lot would argue this is SSR and it is in a traditional sense the server is rendering the page but it's generating HTML and it has no idea what happens after the fact what SSR usually means nowadays is something more granular it's rather than rendering your whole page with HTML and sending the whole thing to the user it's some combination of that in a component model where some components are rendered on the server some aren't but you get to write your JavaScript code once and that's the magic of SSR is the code that does this part in this part is the same as the code that does the earlier Parts on the server so you can write your react code once generate HTML to get the benefits of this but also have a good update later on the client side from that point forward so we have a request we'll say again getthing.com so let's be very clear this is using roughly the next JS model for server-side rendering so we get thing com here is where a few different things could happen when this request gets to the server there's a couple different things you can do you can have a cached static page that you return immediately so one option is immediate return SSG static site generation so HTML file already made and build another option that's kind of specific to next that's really cool is ISR immediately return cache page if cached page is still valid ISR ISR is a cool concept where you could have a thing that was generated and rather than a thing existing forever and now like it's out of date you can manually revalidate it when changes happen so rather than regenerating your whole site when you push or having to tell your cash to throw away old data when changes happen with versel you can individually invalidate a request and say hey this URL the data that it returns is different now so the HTML it returns should be updated or you can set it with a timer where depending on how long it's been since someone last requested it it will give them a cached result immediately but also check in the the background and say hey is this out of Date Update it if so for the next person or what we're more focused on right now full on SSR new page generated on every request for the sake of keeping this simple I'm going to focus on this third one I have a bunch of other content about these other two but I really want to be focused on this and the benefits of it because the goal here is to go deep on why generating unique pages on every request can be valuable the first thing to know is that means this section is going to take quite a bit longer similar to how long it took above here so I'm just going to copy this exact thing and make sure we're being relatively fair with the representation it might actually be slightly longer because it's running in JavaScript instead of PHP which will be a bit slower and on top of that you might be running on serverless which means cold starts so in this window the browser is loading the HTML which means for most of that time it's just sitting there waiting for the server to finish its page generation so here we have thing.com index.html this HTML page will actually have stuff in it though because as the server this is going to run the react code you wrote and do all the things it needs to especially now with server components where you can await data in a component what the next server will do is make sure the whole page is rendered and all of the data fetching is done before the response is sent to the user which means that as soon as we hit this point the page now has the correct data being shown so as far as the user is concerned looking right here page loaded we still have to do the other things we did specifically fetching the JavaScript because again the client still needs to be able to update what we've done here is just a first pass on the server so the server has now fetched and rendered and made the HTML for the client but in order for the client to change it still needs to load more JavaScript to take over so at some point this all comes down this will actually be very fast because it's coming from a CDN and then this will parse it and after it's parsed any API request it needs to validate the data it will start doing but there's some amount of time spent parsing here too regardless I separated this because I kind of light here the page is loaded but the interactions haven't because without the JavaScript buttons won't work form submissions won't work all of the things we do in our JavaScript won't work so in this window it's loaded but not hydrated hydration is the concept of JavaScript libraries that read the HTML and then take over from there because they were used to render the HTML before because there's a window here where we have HTML that is correct but the actual JavaScript that runs the page isn't here yet buttons won't work links won't work the interaction isn't here yet and that interaction doesn't happen until the JavaScript has fully loaded parsed and hydrated the page I don't think resumability is a big deal but there this window and depending on how slow your device is and how far away the cdns are and how hard it is for your device to parse the page and catch up this window might take a bit but this window doesn't affect you unless you're clicking buttons until you've clicked something hydration isn't too big a deal and once this JavaScript is loaded on your device usually it's cached and it will be much faster in the future this is on first load further loads this will be way smaller almost immediate but for that first load this can take quite a while and the timed interactive is the term for this window how long from when the page loads to when the interactions actually work and I don't think this is that big a deal when you move from Spa to SSR the thing you're trading is these awkward states where the UI is incorrect in changing a whole bunch and you're trading that for a longer window for the first load but a significantly better experience of the page loading in with the correct information really really powerful pattern and with the new react model specifically with the new server component model before then this is for the whole index.html like the entire page content the whole page is like this in the new model we can have like 15 of these that are all different for different parts of your app so we can have app it'll have feed which is the feed with all your posts and I'll have post there's a given Post in the feed app can be it's all hell so we respond almost immediately here we get data to the user but at the same time in the background we've already started rendering the feed and the posts the posts might come in a little later but in this time we're actually showing a page to the user so we already have a response to the user while we're also triggering these running on different servers so app renders almost immediately hits some cache data gets you HTML ASAP it's going to be like your traditional Skeleton thing maybe we can even get your profile image in here ASAP because we have that in like the cached headers or your cookies with jwts it's somewhat easy to get a really quick response to the user with a scaffolded HTML page with some data in it but then we need the feed to load so rather than waiting until the feed is done to send anything back we send you back HTML immediately and the server is in the background rendering the feed you can think of this if you've seen suspense in react before you can use suspense for this so app renders feed in a suspense container feed sends back the loading State until it is done some amount so here it is now generated something and at that point we get an updated HTML page maybe that has the feed in it but maybe some part of it's missing like we have to go somewhere else to get the profile picture data which is why posts haven't loaded so they've done this but we have maybe three posts and all of these posts are now loading Instead This is not ideal obviously you should block until the posts have loaded on the server but in case you haven't this would be the next loading State and while that's going on you've also triggered more renders to happen to fill in your suspense whatever you're putting in the loading State here and now this request is happening this one isn't going to do anything else it's just going to return a good state that immediately gets passed on and then you have the actual UI rendered and you have a lot of control over when these things come in because at every single component you get to choose whether it suspends or blocks by using a weight and using or not using suspense and all of this is triggered by a single request the user made to the server and then the next responses are streamed from that point onwards so they get HTML immediately and then they get updates to change the rest of the page and if you have had something else you wanted to load like let's say we have like an ad feed that is separate and have ad feed here and this can have its own whole separate pipe way out here and come fill some blocking on your page later and be entirely unrelated to the feed and post because this relationship is just your component model we're using react components to render data when we get it the only loading states are the ones you choose to have not the ones you have to have because the client's waiting for data previously as I showed here SSR meant the whole page loads all of the data and you don't get to see anything until it's back here SSR is a more a la carte type thing where the level at which you start and stop ssring is up to you and different components can have their own SSR trees it's a bit complex to wrap your head around and I hope this video helps some amount but the specific point I'm trying to make is that the content the user gets the actual HTML that they receive is being generated by the server rather than the user's device which makes a lot of things simpler it means you can fetch from database directly and immediately render it means means you don't have to worry about loading States all over the place it means waterfall is where you fetch data to get some process and then fetch more data to get some in process happen way less means you ship less JavaScript to the client it means your metadata in your tags when you post your links on Twitter and Discord are going to be correct now all of these types of magic are only possible when you're generating HTML in the server and what these new react changes you have much more control over what is generated when where and why this approach is a new hybrid SSR model that react is pushing really hard with react server components it makes it really hard to not render your react app on the server at least a little bit because man these patterns are powerful hope this one was helpful it's a bit different I usually come into these diagrams with a little more of an idea before I start but I have gotten these questions enough and had a number of people asking me what is SSR and do I need it I hope this helps answer the question most sites and most experiences should default to SSR where they can so you have to deal with less stuff less loading States less error States less ways for things to go wrong and server components will make it easier than ever to serve render exactly as much as you need super excited for the future reactors enabling here can't wait to play with the stuff more I have a video pinned here about some craziness with how this works inside and next comparing it to other Frameworks if you're curious so check that out if you haven't already it's a great video thanks as always please start

Channel: Theo - t3․gg

Views: 162,558

Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg

Id: kUs-fH1k-aM

Length: 18min 14sec (1094 seconds)

Published: Thu Apr 27 2023