When should you use Server Components?

[00:00 - 03:30] Alright, welcome to the last lesson on the topic of server components. In this video, we're going to go over some ideal use cases for server components as well as some not great actually really not recommended use cases for server components. So you can have a very idea when it comes to architecting your page when you choose one or the other. So consider that server components are a perfect match for parts of your application that do not require interaction with the user. That is key. They can render all the static HTML access server side resources and even serve as an intermediary between the client and your backend essentially. The best scenarios for or some of the ideal scenarios for server side components include rendering dashboards or reports essentially displaying blog post or any other static content that you can pull from a database for example or even server side data fetching where you want to hide the data fetching logic from the client for some reason. So go in a little bit deeper in the case of dashboards and reports you're maximizing the performance by processing and rendering all the data on the server. Consider the opposite option and having those reports or widgets on a dashboard be using a client component. You have a lot of extra time pulling that data from your own API end points which would in turn get the data from the database for example and then just waiting for that data to come back to the client so that it can then be processed and plotted. With server components your reports get rendered directly on the server and then you know each potential widget inside of your imaginary dashboard could get streamed to the client in parallel so that is a much faster alternative to be honest. In the case of blog post or static content you're pre-wrenching that content on the server side. So in the case of SEO there is no impact in fact you are optimizing it for speed so that is also something that is going to be abus for your SEO. You don't lose any dynamic of content not coming from the database in fact you can still pull content from the database or any other you know source for your blog posts or any other static data but instead of waiting for the UI to load those posts and then render them you get all that content directly rendered on the server. If you want to go back to the previous video and compare again server side rendering and server components this particular use case is probably what conf uses most developers because when you think about SSR you usually think of static blocks like what Astro does for example where you would have your your mdx files with your articles and then the static static then server side rendering will come into place it would translate that into HTML and then gets rendered on the server. If we were using server components for this the process might be similar but it's also about thinking about what else is around your application and in your UI.

[03:31 - 09:04] If you have very simple blog with just showing static content then SSR and server components in this particular case might be very similar while in practice functioning differently the end result will be similar however if around your static blog post you have a lot of other pieces a lot of the components or some of the interactive some of them are being static then server components will be at advantage of our SSR in comparison. Finally server side data fetch ing this again is a security boost if you will to your code because you're securely accessing the database or any like private API that you might want to use without exposing that logic and potentially even accidentally exposing like API keys or any other secret that you don't want to be on living on the client side where anyone could see it. You can do pretty much any operation on the server components without running into the risk of exposing exposed sensitive data to the client. Conversely server components are not designed for areas using user interaction essentially like forums buttons. Another really bad use case for server components is that of stateful components and take this with a grain of salt need to move forward with the curse and get deep into how state works with server components but but in the strict sense of the word and considering how we've seen state up until now which is data that lives on the client and gets somehow remembered on the client then we can say that server components don't really have access to state. They I mean we already know that they don't have access to state related hooks so we know that much however at this point we can say that server components are not stateful but we'll review that statement in future videos and now let's quickly look again at an example that we've seen already this is the navigation bar component which again we've seen that is a server component but one that shows a perfect use case for server components which is why I wanted to look at it again. Remember that server components being run and executed on the server are able to perform data fetching faster because they're closer to the database in the sense that there is no HTTP delayed between the client and the server to initiate the request to the database instead here we get the an immediate request to the to the database once we hit the line where it's calling the get user by id function and that happens upon the request arriving at the server there is no client involved or round trip involved between the client and the server before this function gets called so this is much faster data fetching already and then again we're rendering the static html of the entire component using the content of the database that we received if we think now of the react server component payload we will have the html for navigation bar 90 percent of it without the user menu essentially component inside the payload would also be the place holder for the user menu which is a client component and we would also have and this is why I also wanted to run you by this example again inside the payload we would also have the user data the user data that we got from the database and that we're passing as a prop to the user menu component because we're doing that because we're propping that data into a client component then the prop is also bundled in the payload that gets streamed to the client then in the client the user menu component will be instantiated and it will receive the data that will pass to it so again I know you already seen this component but I think that seeing it again with another light now that we don't have more details about the payload that gets transferred and how it gets rendered it makes a lot of sense to review it again so in summary server components are a very powerful tool provided by NEX actually provided by react but really made popular by NEX 13 when it comes to static non-interactive content so that is key it has to be static non-interactive content because otherwise we would have to default into client components on top of that they offer a very secure and efficient way of interacting with database or any other server-side resource like the file system for example leaving client-side work to the client components so there's a clear separation of concerns here whenever you need static non-interactive or heavy server-side resource work then server components are your go-to type of components otherwise if you need some interactivity with your users then client components is what you're looking for so that's it for this module in the next one we're going to go back to reviewing page architecture a little bit more now that we have more information on all these topics and then we'll continue going into answering the final question which is how to share stay between client and server components so in the meantime see you in the next one