Server Components: The Epic Tale of Rendering UX

Hey, everyone. Today, I'll be talking about one of the very coolest things that React has been working on, which is server components. We'll be diving into different concepts, but I will be explaining the things in a little more fun way. Without any further things, let's try to see what we are planning to cover in this talk.

You might be thinking, maybe what's this guy going to tell us? What are server components? How they work? Blah, blah, blah. They can be a thousand number of things. I would just say, for this talk, because I want to keep the theme of the talk as simplicity. Let's just have only one agenda in our current talk, which is just a short story, and let's try to uncover things based on the short story itself.

All right. So, before diving in, a little bit about me. I am Nikhil, and I work as a software engineer here at Postman. I usually work on super fun stuff like design systems and the overall foundation of user experience that we have set up here in the product, so I work on the bits and pieces of all of these things. Yeah, other than that, I love to talk about everything that the web is doing and it's heading to in general. So I love to talk about performance. I love to talk about how the front end is going and what new is coming up. So, yeah, if you want to, if you're like a geek, like a kind of a geek like me, so I would love to connect on Twitter, on GitHub. You can find all these handles which I'll definitely share with you all. So, yeah, I would really love to connect with you all.

So okay, so now let's get to the fun part. Now let's start a story with a guy named Bob. Now, Bob is a person who is at a beach and like accidentally, he does not have anything to create a sand castle on a beach. He loves building sand castles. But like what he has to do is he has to see, okay, there is sand and I just need to use my hands, like how we used to do in childhood, right? So we need to, like he just needs to build this sort of thing with just some hands.

So the responsibility of building the sand castle is like probably only on to Bob. He has to figure that thing out. He does not have anything to help him out. Now, with this starting gist of the story, this is what you would, if you relate to it, you would see, this is how client side rendering right now works, right? You will have a server and you will have someone like a client that is going to request the server to do something. In this case, like as a Bob wants to build a sandcastle, maybe, you know, a client wants to build a web page. So he requests this from the server. The server is going to give it a response, which is, you know, a list, like a JavaScript files is going to give it HTML files and CSS. And it's the client's responsibility, like, you know, Bob is, it was Bob's responsibility that he has all the sand and what is the disposal and he has to figure out how to build a sandcastle. So this is what the browser does as well. The browser creates the final website basically. And like when everything is ready, this is what you see on your page, right? So like pretty much simple.

Now let's get to the next step of the story. Now the next step would be now Bob remembers, oh, I don't have anything, so let me take some help. So Bob takes helps from his sister, Sarah. Now, Sarah has like, Sarah is also very passionate about building sand castles at beach and like she's like very well equipped. She has like, like these good sets of tools, like you know, a shovel, like, like a basket and like she can do things like very, very quickly and easily. So Bob takes her help. And there's now like Bob just gives everything as a responsibility to Sarah. And he says, like, yeah, build the castle for me and like I'll just use it. And now if you understand the analogy, this is now what SSR is, right. So SSR or server side rendering is where you tell the server that I don't want to do stuff myself rather, please help me build the website for me. Right. So now how it will differ in the in, in terms of the timeline is now whenever I'm requesting the server for a website or like a webpage. The server is not giving me the resources like HTML and CSS. What it's doing is like it's creating the final HTML output on the server in itself. And I get that HTML output on the client. Now when I get that HTML output, I use like, like now then like now I see like something on the page. For example, like, if there is something that does not have JavaScript, but there are some, you know, very static content like some about sections of a page which do not usually have interactivity with them. So this is like a bare minimum that I can give my users on the face so that like they are like not staring at a blank screen. And when the JavaScript is available, like when the client now request for the JavaScript seeing the HTML, now I can hydrate my application and it actually becomes like totally ready for users to interact with as well. So this is basically what server-side rendering does, right? So far so good. I think we all know all of this basics. Now what I want to divert this story towards is what we want to focus towards in this talk. Like, what are we all know like there are tons of advantages and disadvantages of every type of paradigm that we have here. Right. So let's like look at them like one by one, very quickly. So if you see like, I'm not going to tell you like some patterns of both of these techniques and like what are the pros and cons in a nutshell. So, if you see one client-side rendering has like better subsequent page loads, whereas for server-side rendering, it's better for like an initial page load, so it can give you content faster in compared to client-side rendering because like, you know, it has to prepare everything from scratch and it's end on the browser. And secondly, client-side rendering does a good job after the initial page load work is done. Right. So, if you go to like different routes and you try to see different pages, only that JavaScript is refreshed, which is actually needed.

So, like a lot of refetching is saved because you already have like majority of the stuff on your plate, but with server-side rendering, every time you like go to the page or like maybe you refresh the server-side rendered app, it has to like do all of this stuff every time again and again. So, it can lead to like high server-related costs as well.

Now, like client-side rendering applications are great for like creating PWAs while like the client-side rendering is better with search engine optimization. And the fact is really simple because it has like you're showing something on the page and the web crawlers, or the different APIs can like have access to that information so that they can show it on the websites. So, so far, like we have like these set of advantages. And if you see like disadvantages, again, like client-side rendering does not have what SSR has like initial page load. what client-side rendering is having like, like subsequent payload. You have to do like rendering stuff and creating the web pages on the browser again and again. And client-side rendering is again bad for SEO, which we already mentioned in the advantages section while SSR is, you know, good with stuff like, like things like SEO. So like with, with that in place, let's like just make all this list a little bit shorter and focus on only these two things.

So if you see one thing is good and one thing is, and the same thing is like, which the other technique is not good at, right? So in this case, one has a good initial payload, but the other one does not. It is good with subsequent payload, page loads. One is good with, you know, with static pages, for example server-side rendering, because if you have interactivity and JavaScript in that, like it's again, going to take some more amount of time to render your page on the server. Because again, JavaScript is going to take some time. But in case of client-side rendering, it's good with dynamic pages, right? Because you're like rendering everything on your end on the browser, right? So far so good. It's simple. So we know that, okay, one thing is good and one thing is not, in some other techniques as well. So like, you know, you don't get the best of both of the worlds, right?

Now, imagine another part of the story, and this can be the, you know, maybe the climax of the story. So let's say now, instead of Bob calling his sister, maybe what would be better if like, maybe Bob had access to all of these, like, you know, really, really cool tools to build the sand castle, right? Like, if you would have like access to all of them, like he could maybe choose like, you know, how to like putting it in our analogy how to basically get both of the advantages, you know, having somebody else to help bring the castle versus how we can build that stuff together. So maybe he can like merge both of these benefits and disadvantages together with only the set of tools maybe. Right. And this is basically the, you know, what server components are that the React team has introduced. Right. So, several components are like a new. So if you talk about in, you know, technical terms, so several components are React's new way of abstracting both the goodness of client side and server side rendering, which actually like instead of giving you a page or like HTML CSS or like something as an HTML kind of an output, like both these techniques do, it gives you some intermediate abstraction format that you could say, where it can help render things faster and it can help you choose what is it that you want to render things on the client, versus what you want to render things on the server in the same page, because server side rendering does not allow you to. So let's try to look at how server components is changing these things, right? So let's again, see a very simple diagram of a client and a server. Now, so like client again requests for a webpage. Sorry, server gets, now server is again doing some part of server side rendering. It's actually rendering your server components on the server. And now, instead of giving you this output, it does not give you your HTML or like server side rendering, some output that you can directly show to the browser.

It gives you some, you know, a very JSON-y or like it's a very weird type of format, but it gives you a special format of data. Now, this is not for you. This is for React to figure out how it can render these components faster and like merge all of your changes that it has made on the client, merge them back to its Virtual DOM tree, right? So this is like the simplest way that you can put it.

So it renders some parts of your page which are server, like server components. It renders them on the server. It gives you some data and it finally like generates, like your, your, your client actually is going to do some rest of the stuff. It's like not that much heavy, but it can do that part much faster than client-side rendering. All right.

So talking about the pros and cons of all this stuff is what do you get basically out of this technique, out of all of this FSR. So one thing is you get zero bundle size and you are right when you're hearing that. So server components are running only on the server. So you never ship the JavaScript that we have run on the server. So all of the components, you can like maybe a thousands or hundreds of components, none of them actually get shipped to the client, which is exactly zero bundle size that also in this example you might have been seeing, Dan Avermoff had also shown in one of the talks. So this is one of the very biggest pros. It like helps you make your client's side bundle be a lot more smaller. And also as I've been saying this whole time, you get the best of both worlds, which is both client-side and server-side strategies combined in one technique. So imagine something like this. You have a tomtree. You can have something that is being rendered on the server. There is something that is being rendered on the client. We talk about the implementations, how you can do that. But you can tell React that, okay, some parts of my web application are to be server rendered. And in the same page, some of them have to be rendered on the client side. So you can give that indication now to React. So which was not there on server-side rendering, and now React will handle the rest of what parts to work on on the server and what to just skip it and let the client handle. So this is a very magical and a very powerful thing to do. All right.

Going to the next thing is automatic code splitting. Now, I personally like this because, you know, like currently you would see, we have to write a code which is something like this. You have a plain React.lazy library, and you can lazy load your components as or need them, right? So you have to like write some stuff.

So, with server components, those React.lazy APIs, they go away because they handle this for you. Now, if you see in this example, like I'll just maybe go to the previous slide and show you. So you had old photo renderer and new photo renderer, these two components, which were like client components, and you were lazily loading them. But now, since everything is being rendered on the server, so server components, like on the server, they can actually segregate all, like what all client imports do you have, which are not being used while rendering your final server component, that can compose of your client and the server. So it can actually do that code-splitting stuff for you. For example, in this case, if the feature flags like new use photo renderer is true, only new photo renderer component is going to be loaded as part of the JavaScript here and not the other one. All right.

Going to the next step is you like, if you like imagine this scenario, you have your components which were earlier on your client but now we have shifted these very React components from this client side to the server. So like since we are like very close to the server, now we can have like more faster and like direct calls with the server and the response that we can get from the database, it can much more faster I would say as compared to the usual fetch calls that we do. So it's super fast than that. All right.

There are some things that we also cannot do, which is with like, although you can use like client and server components, both like in conjunction on the on the server things like states effects, which are usually like the things of client components. Server components do not support that. So these things are something that you cannot use. They're a very good thing. If you want to imagine something, server components are usually used for displaying some data or like making some fetch calls or doing sort of data fetching. Whenever there is interactivity involved, you would go with client components. So I would like just say there is the thumb rule, data fetching or display stuff with no interactivity, server components, interactivity and like more richness, you have to go with that's how we need to segregate those two. The next thing you have to, like if you like you can have server components and you can also render either a server component inside a server component or you can render a client component inside it. But only like you can also like pass props from like server components to client component, but only the props, which are serializable over the network, because the server components are not rendering on the server. Like they're gonna, sorry, the server components are rendering on the server and the client components are not. So you have to, like, if you want to share data between them, they have to like, go through the server link. So only the serializable data, like, you know, objects and strings, numbers, things like that. They can like be easily be serialized. But things like, you know, functions, you can't, you can't use them as like, you can't like pass them as a prop. So this is one limitation. So, okay, now, yeah, now let's see how to actually use server components. Like what do you need to do to get just get started? In React like, I think many of us might have already seen the talk of like how React team had been demoing it. But like, you can use a .server.js extension to indicate as for the example that React had mentioned, how to create a server component. So this is an indication that this component is going to be rendered as a server component on the server.

Next.js does it in a different fashion. So it has like, it tells you that, okay, everything that you create inside the app directory, that's going to be a server component by default. Although you can do also like you can do some tweaks, you might be wondering like, how do I like create a client component if I want to create a server component? Like how do I like, you know, choose between the two. So you can just like one line, which is use client directive. Now this is going to help you just tell the React that, okay, this is nothing. It's not going to be rendered on the server, please render it on the client. And that's how it makes that distinction.

All right, enough talking. Let's now actually go to the demo and like see how things are up. Now I've opened this very small demo here as a separate page. And this shows you a very simple thing. It's just an API call that I make on every reload, and it just shows you a dev joke. Like you have a question, and then like it just gives you a punch line or like an answer. Like in this case, like why do assembly level programmers need to know how to swim? Because they work below sea level. Nice one.

So this is how the basic demo is. So if you see like the disadvantages that we had been thinking about client-side and server-side rendering. So client-side is actually rendering things upfront when it gets the data. So like how you would, how you can like test it is if I refresh my app here, I would see that there is some static data that I can get as part of HTML, but since Javascript is not gonna be loaded, I might not get all of this stuff. Which is like the question and answer that I'm fetching as an API call. So if I refresh, you would see for some time, I don't get the question and answer. I just get the static content that I've hardcoded because that's how client-side rendering works, right? It is still getting data from the server and when the Javascript is there, it's gonna render things out. It's gonna build the sandcastle on up front. So that's how this happens. You guys already know how server-side rendering is gonna behave in this case, I guess, no? So now we are preparing everything on the server. We are not waiting for, we are not doing that thing on the client. So if I now refresh this page, I should not see a blank area, I should see this up front. So if I refresh, you see, oh, okay, maybe I think I'll just restart. Okay, something with the older build, I don't know. Okay, let's see if this restarts. Okay, yeah, here we are. So if I try to refresh, you'll see, I see the data, like I see everything up front, I'm not waiting for like a blank screen or like my JavaScript to run on this client or something, I'm preparing everything on the server, shipping it out. So that's how things are happening.

All right, now how server components are different with this. So now let's see some very interesting things now. Okay, so let's open our very old DevTools.

Okay, so let's open our very old DevTools. And let's see what is like basically what actually is it sending you? Like how is it actually working? Now if I refresh this page, you'd see I'm like still getting like I'm still getting kind of the like the data because it's actually preparing things for me as like a server side rendered app. Right. And if try to see what is it actually sending you. Right. Is. Let's go to the. Yeah. So this is what it's actually sending you now. It's like you know some weird set of things that it is using but it's you know an intermediate communication channel between the server and like the React on the client to tell you how to merge all of these things that are rendered on the server onto the client so that the client has to do like minimal work. So this is like what it is actually sending. Right.

Now let's also try to see and I think I have like another example to explain it. Now we talked about how client components and like how several components can be like you know used in conjunction on the server. Right. So if you see I have like a child like a like a client component as a child which I'm not rendering on the server and inside it I'm rendering a server component. Right. Now ideally like from theory point of view we may be talk that the server component it should not ship anything on the client. So I should not see anything in my job. So what webpack is compiling but I might see something on the client. But this line child component or do I need this? Let's go to sources go to webpack. Yeah. So if you see there was an app and it only has a client .psx file which is only for the clients component which was like we had added this everything on the server but react just gives this on to the browser that please render this down as a client component but you don't see any code that is ship for the server component. So there is absolutely zero bundle size you don't ship anything as part of your job set to the server component but the client component it gives you. So it's like very much customizable. Okay so this was one thing. So yeah I think I covered most of this. So yeah this is actually the power of server components. It lets you customize basically what you want to render on the client what you want to render on the server and like not doing all the stuff like again and again. So you get like again like what you are like talking about.

The best of both worlds is like what makes the strategy so much beautiful. Okay so with that being said. Now let's talk about some more stuff. So you might be thinking server components are so great like you can fit like basically they don't have any disadvantages now do they? Like you can like I can use them anywhere any place any time and like my websites are going to be like super performing but like everything has a downside to it though.

So like again like this strategy also has its tradeoff but like most importantly than tradeoffs that we had I think discussed like it being able to use effects or state updates or like you still need a server so like it's maybe it's again or like hamper your server related costs so like those parts are also there. But I think more importantly I would not recommend trying them out in the like trying all of these things in the production apps itself because the current status is I think React team is still like they're doing like a absolutely great job in gathering feedback and being super transparent about their findings and research but it's the same experimental stage in React and if you want to try it out NextJS like you can get started with it with NextJS and this is how I had built this demo itself So it's super easy to use, I would really love for you to give it a try.

A few like if you want to like go like full on through this thing I would really recommend watching this YouTube video from the React team where they have actually demoed you and explained the problem in like in more of details and also explain things up with a really like another very cool demo so I would really love you to try that out and again there is some cool documentation that I personally found like very useful and like it's so simple to understand things for example the official Next.js documentation and also there's a very cool article by Zenstack on to server components and like how you can actually get started with it a lot faster so I would definitely give it a recommendation here.

Okay. The code for this demo you can find it out on the slackbits url so feel free to fiddle with it try to break it do whatever you want to do with it so it's always fun to learn this way and feel free to like shout out at me whenever you see any issues any problems over like Twitter or like other channels. And one of the very last things is like these are some similar sorts of interesting problems and problem spaces that we keep on working with in Postman. So we're also hiring and if you if you folks would want to get part of this journey so feel free to reach out to the careers website and connect cool. This is mostly it that I want to discuss. I hope you folks are enjoying the amazing sets of conference like amazing sets of talks that we have in the event.