Next.js for React.js Developers

Hello. Thank you all so much for making the time to get in here and for choosing this workshop over maybe some other ones. So I hope you're excited about the topic. We'll try to go over a lot of useful stuff while trying not to keep it too boring or too dull. So I'm going to give my best to just make it somewhat enjoyable, enjoyable to watch and listen to as much as we can as we will be diving into some advanced topics as well.

So I'll give my best. I went ahead and my team as well. I got to give huge props to them for preparing even the slides, the presentation, everything. We're going to have some live demos. We're going to have a lot of stuff. So I'm really grateful for you being here. And while people are joining, we can slowly kind of get started.

So I'm guessing that kind of the goal of all of you here is maybe seeing how we can better leverage not only what Next.js is offering, but what React is offering, and then what Next.js kind of simplifies and creates a wrapper off of, right, to better use the React, but therefore, Next.js code in production as well. That's kind of going to be the topic for today.

So diving right in, React Server Components, probably the biggest talk of 2023 after AI. If you've been on Twitter or X, you've probably been seeing people talking about it every single day. Some people love them. Some people hate them. And most people are just confused. We have questions like, what is RSC, as in React Server Components? Isn't it the same as SSR? Why is React turning back to PHP? How does this all fit with Next.js? And can I use it without Next.js? Right now, that's a bit of a mess. I'll do my best to untangle that mess for you.

So before that, a little self-introduction. I'm Adrian, the founder of JavaScript Mastery. We've posted a lot of different educational YouTube videos on topics such as JavaScript, React, and over the last year, a lot of Next.js. And also, I've been recognized as a GitHub star, kind of position offered by GitHub for people that really try to give back to the audience and to people focusing on education. So I give my best to create over hundreds of project-based videos where we teach developers how to build real applications start to finish. And I've been working with the new Next.js a lot, ever since it came out, almost using it in all of our YouTube videos. We had it a lot, building real applications, teaching it in our Next.js course as well. And it's completely new Next.js. All from 13 to 14 and even further, there's a lot of new stuff happening with Next.js. We also created the Next.js course right here that almost 3,000 people have joined. And in this workshop, I'll explain what I've learned about React server components and how they connect with Next.js in a way that's easy to understand.

So let's begin with a warm-up on pre-React server component era. Things were simple and straightforward. React was guaranteed to run on the client's browser, nothing else. Simply ship big chunks of JavaScript bundles with minimal single HTML file and tell the client's browser to handle everything else. The process, as we know it, the client makes a request to the server, which looks something like this. The server responds to HTML and JavaScript bundle. The client renders HTML and downloads everything mentioned in the JavaScript bundle. The client executes that JavaScript and then paints the content on the screen. This was surprisingly amazing web invention. It still is, but like all things, it still has drawbacks.

Yes, even React has drawbacks, the most important ones being performance. The more JavaScript you ship, the longer it will take for your site to load initially. And in today's world, the first impression is crucial to keep your users engaged on our websites. We also must not forget about the low-end devices, where we presume that all users have top-notch devices, networks, and browsers and trusting that their browser could handle it. Yet, not everyone owns the latest devices, and we can't overlook the fact that over time, we're not incorporating increasingly advanced features into websites. If you've experimented with Next.js during development, you might have observed that it doesn't perform optimally on MacBooks with Intel chips. They're powerful machines, but new technology is demanding. As new technology evolves, so do challenges for users on less advanced setups that were powerful some day. And of course, we can't talk about React's drawbacks without mentioning SEO. Yes, yes, you heard that multiple times, React doesn't play well with SEO. It would have been amazing if web crawlers understood JavaScript, but unfortunately, that's not the case. And with minimal HTML from React, our website doesn't get to properly understand SEO. So, to address this problem, Next.js implemented SSR. SSR, server-side rendering, this method involves rendering React on a server, generating HTML, and then sending it to the client. The client is then responsible for rendering those HTML nodes and elements and incorporating the necessary JavaScript to enable interactive content. It's important to understand that as of now, SSR can only render React components that are suitable for rendering on the server. Components requiring interactivity, such as those with event listeners or dependencies on web APIs, aren't executed by SSR. You can think of SSR as a method to create a blueprint of our website. It generates and displays how your webpage will initially appear.

For example, consider the following scenario on the page. We have a home.js file, or we have a typical counter that you've seen hundreds of times. I believe it was also featured in React.js docs as one of the first examples of using states when hooks came out. How many of you were here for React 15, React 16, when we transitioned from class-based components to just hooks? Feel free to let me know in the chat. Not a lot of new generations of developers that are coding right now have been through that time. Have you been here for that transition? Yeah, it's crazy to think that some of us have started with class components and some of us, or some of you maybe, have never used class-based components, which is a pretty interesting thing to think about. We have this example right here, and the result of the SSR output would be like this, where we simply have welcome to my new Next.js app. Where we have the button and the counter. That's the SSR. An HTML page is produced here, comprising a list of elements and nodes, representing the components of that page. But what about interactivity? All the states and event listeners are dispatched to the client and as JavaScript bundles, which the client browser loads and initiates the construction of the virtual DOM. The client compares the static DOM we received initially with the virtual DOM it will create using the provided JavaScript code, and then determines if they properly match. If not, it will throw an error, saying that many Next.js developers are frustrated about, which is going to look something like this. A hydration error. This entire process of reconciling the virtual DOM, which the client believes represents the page, with the actual static DOM that the server delivered, is called hydration. Everyone's favorite, Dan Abramov, put it in this way, through his mental models. Before, so without the SSR, we have the React tree, where we render components to HTML. We have the main.js and then we bundle the code for interactions like this. And then after SSR, it's going to look something like this. Where we have the server tree, with the file system, databases, internal services, and a lot of other stuff. And we pass props to the React tree, like this. Basically, a virtual DOM, or tree, created by the client, which looks like this. Server, client, and now we have everything happening on the client as well. Yeah, I can see in the messages as well that Davie sent the builder.io React hydration overlay. So, that's a pretty cool thing to note. We can also definitely share it in the Discord, so whenever we have anything, we have a forum and we can keep our discussion there. It's quite useful to know that we can have better and improved error messages when it comes to hydration. Thank you for sharing that. But that's enough about SSR for now. You get it. Since we have this solid SSR approach, why should we bother with React server components? Well, the conventional hydration we discussed earlier, before React server components and Next 13, involved a full page hydration. This meant that when the page loaded, the entire React component 3, including all components, whether initially visible or interacted with by the user, were hydrated on the client side. What does this mean for performance? Although you can see something on the page, it won't be interactive until the client loads everything related to that page, specifically the necessary JavaScript bundle to hydrate the static tree. Sure, we achieve a faster initial load at this stage, but then there's a delay we can interact with, and because we're waiting for the JavaScript to hydrate, there's a gap. For more extensive codebases, it can lead to larger initial page loads and processing of JavaScript, even for components that may not be initially required. So here's where the React server components step in. React server component is a fresh component type. It's assured to run exclusively on the server. They never get hydrated on the client side. So as a result, no extra JavaScript is sent, resulting in a smaller JavaScript bundle size, faster page loading, selective hydration, and an enhanced experience for both UI and developer experience. But before that, let me explain how does React server component work and how we can use them. It's important to note that React server components are exclusively a React feature. There's been a lot of debate on the internet now.

Hey, why do we need Next.js if this is a React feature? Not sure where you stand with that point, but it's pretty simple, right? React server components are an exclusive React feature. But it isn't tied to any specific framework. Although, currently, the recommended way to utilize React server components is through Next.js. Here you can see it mentioned right in the official React.js docs. It's technically possible to use it independently. Nevertheless, using it without a framework is not advisable for production and the setup can be a hassle with pure React.

You can check out the demo right here. Before we check out the demo, I want to ask you a couple of questions here. What's your stance on that? Kind of using React server components independently of a framework? Have you tried doing that before? Have you tried to use it for larger codebases? I know it's hard to break the ice, but I always like to have some interaction happening as well. Feel free to use the chat as well. Might be a bit easier. I see a couple people just saying that they haven't used React server components yet. They're quite new. React didn't really provide a simple way for us to use them. But if I asked a question, have you used React server components with Next? The answer changes dramatically, I'm guessing. Give me just a quick yes or no if you have used them with Next. I can see a lot of yeses right there.

This is the official React server components demo right here using just React. What you can see here is that we definitely can use it. We have the server, but it needs a server. Here we can see that inside of the server, apiserver.js, if we scroll down to the app.get here and I'm going to zoom it in just a tiny bit. We have this app.get forward slash, and you can see that we're sending HTML back right here. So this is technically React server components in action. It's getting them from the server and it's returning them back. We're now diving into the official code base. Moreover, the React or render React tree right here isn't just constructing the React tree as we discussed. It's handling various tasks, including sending responses and creating routes for other pages as well. So if we step outside of this folder and inspect the package.json file right here, you'll notice that we are utilizing React DOM server webpack right here, this package, 18.3.0 next version right here, and we're also using the server only package 0.0.1. That's a good one. This is the process when using React server components without any framework at the moment. It requires us setting up our own server, scripting and handling rendering independently. And this is where frameworks like Next.js become valuable. Using a React server component in Next.js is effortless. And the latest version of Next.js, the app router, makes the RSC the default component, as you all might know, which is pretty exciting. So now I want to dive into a quick demo. Yep. We're going to have demos as well. I haven't prepared any videos for that. It's going to be just a quick, good old Visual Studio Code demo, which, as you might know, often go wrong. So bear with me. You cannot have a demo without something going wrong, right? What we're going to do here is we're going to ensure that we are on my desktop right here or rather just create a new file right here for Git Nation. All of these files will be provided to you in the Discord server later on, and we'll be able to have more conversations about that as well. So we're going to start from really bare beginnings by creating a new terminal right here and creating a new Next.js app by running npx create-next-app. Let's choose a name. In this case, we can do something like hello-rsc and I'm just going to press Enter for everything. We're going to get the default settings, and this is going to create a new basic Next.js file structure. Now there we have it. We have our own application and the component, of course, is within the page.tsx. This is our first React server component. How do we know? Can somebody let me know? How do we know that this is a server component? Yeah, that's correct. Radik, I hope I got that right. Simon as well. There is no use client directive at the top. That's it. It's as simple as that. We don't have to do anything else. Next.js does it by default if we don't go out of our way to specifically provide the use client directive. Great. So, now let's go for a quick demonstration right here. If we add a console log right here, let's do it maybe right here at the top, console.log, and if we do something like hello-Rome-rsc right here. Let me try to spell it correctly. There we go. Hello from RSC. And now if we run our application by running NPMI, which we first have to navigate right here. So moving to hello-rsc, run NPMI, and then run npm run dev. If we run it and if we visit our app on localhost 3000, there we go, I believe we can see hello from RSC right here in our terminal. And if we open up the inspect element right here, you'll be able to notice that there is absolutely nothing happening in our browser console. Right? Pretty simple, but we do see it right here in our terminal. So if we inspect the view or view the page source of this application, we can do it right here and go to the HTML part as well in the elements. There we go. Bear with me. Cool. So we can see our CSS, which we're not concerned with at the moment. But we can see the script tag right here. The last script tag, I believe it is. And we can see self next push right here. And this script tag is going to display the actual content of the website, as you can see it here. Name, viewport, content. Why is a script returning HTML here? Right? Well, despite being a sizable code chunk, you can directly see the actual content here. Before I explain that, let's go back to the application and I'll quickly show you something. Let's navigate to the dot next folder right here. And I'm going to put this just on the side for now. Oh, if it lets me drag and drop it, not yet. I'm going to put it right here and we can go to the dot next folder right here. This is where the content rendered on the server will be visible. Open the terminal and run npm run build. I'm going to put it right here. Feel free to replicate this later on in case you want to learn or just, you know, learn learn with me by running npm run build right here. Now pay attention to what unfolds in the server folder. That's a lot of stuff happening, right? Now inside the server folder, there's a lot of files.

If you open the app folder in there, you'll find our generated HTML files. If we find the app, here, you'll find all of the generated HTML files. Formatting this just index HTML will show you the exact code we had on our page.tsx, which was a pure server component.

Right underneath, there is something called index.rsc. You can see it here. It might not look very readable, but let's ask ChatGPT to simplify it and make it understandable for us. If I do this, I can kind of open up a new window. Let me just do that right here. Oops, I think I lost it. Let me do it on my other monitor and I'm going to bring it in. This is another, I guess, point of topic right now and to discuss. How often do you use ChatGPT in your daily workflows while I'm trying to get it open and running, especially with development? Have you tried using GitHub Copilot? Are you still staying on ChatGPT or using it literally never? Okay, I can see, yeah, I can see some people have said almost never. And then I have most days, Copilot and ChatGPT as well. That's good, yeah. So if we do this right here, and if I try to just ask it to explain it for us, or at least say make it readable, let's see what's going to happen. Okay, detail structure, HTML and CSS elements. Okay, to make it readable, break it down into components. And now it's going to do its own thing. I'm using GPT-4, it's a bit... Yeah, it's a bit slower, but it's going to go over the actual thing, should simplify it. I think at the end of its discussion kind of explain what it is. But you get the idea. Essentially here, we should have a tree representing the page content, displaying all the elements from top to bottom. So can you simplify it? It can be a hit or miss, as you might know, right? So it immediately knows that it's a Next.js page, and it just appears to be explaining it. But I was wanting it to provide me a tree, but that's hard to see. Essentially what we should be getting if we try to dissect this, you're going to notice a tree of different elements, right? So and try to remember that mental model created by Dan Abramov. React server components don't directly produce HTML files. Instead, they generate a virtual DOM structure, like we see right here. And that's how React, the library knows what to do. So now what we can do is, I guess, just ask ourselves, when should we be using React server components? Let me see. Give me one second. If we go back to our demo right here, there we go. We have this huge thing right here. And currently, we're not utilizing any client component. I guess the question is, why would we use any client components whatsoever, if we can use server components? Well, let's try to create a small client component inside of the app folder, to just try to compare the differences between how they're being rendered in the background.

So if we go here to the app, let's create a new component, I guess we can call it client.tsx. And we can run rafce just to get it going really quickly. And we have our client component, inside of which we can use the use client directive. There we go. This is pretty simple. What I would want to do as well is create another sub component, const sub client component as well, which is going to look like this. This sub client component can just return a div that's going to say sub client component. Now we want to modify the page.tsx file to write something basic, which is going to allow us to get the minimal RSC. So if we go back to the page, I'm going to just replace this entire main, and where I want to get to is just return a main that's going to say something like welcome to git nation. There we go. And we can add a P tag right below. That's going to say something like this is a server component, okay? We're doing it step by step. Now let's see what we get without importing this client component inside of our main page.tsx. Let me see. If we try to run npm run build one more time. Okay, as you can see, it's building it. It's taking a bit more time now. And within our.next, we have server, we have app, we have the page.jsx once again, we have static too. There's a lot of stuff happening. And then we have the pages, 404 and 500 getting generated automatically. Let me just see what I was after specifically here. If we go Oh, yeah, there we go. I can see the chat GPT response provided. And this is exactly what we were after. So if I bring it right here, this is kind of what we were looking for, right? So we have the entire version simplified version of the code, or we have the code chunk one, code chunk two, code chunk three, code chunk four, which is huge, and contains all the children right here with class names and everything. This is what a react server component is. It is a straightforward restructuring to enhance readability in this case. So that's how react server components work behind the scenes to generate and send that data over to our dynamic virtual DOM. And also in there, there is never the code for the client component, the only thing that it has is the code for the server components.

Now this was a quick demo, but I want to dive into answering the question of when should we use react server components in the first place? There we go. So this JS documentation explains it really clearly. It truly is one of the best documentations in the world, where it shows us that exactly when, and it's giving really simple solutions right here. Here we can see that when I'm developing my app, I asked myself, does this component require interactivity? If the answer is yes, right? Let's kind of sketch this out a bit. If the answer is yes, it's a client component. If the answer is no, it's a server component. And this follows the principle of separation of concerns, guiding us to create server components and client components based on their specific roles.

So let's see why should we use react server components? First of all, they're going to be, they're going to result in a reduced client side code, where the proper use of RSC allows us to keep most code and necessary changes on the server side, minimizing or eliminating the bundle size for RSC component to be sent to the server side. Reduced client side code means faster load times and many more benefits. Enhanced security, right? Because fetching data on the server side is more secure than on the client side, where environmental variables are easily exposed. And we know this, right? But sometimes you can fall into a trap of accidentally doing it there. This way it's always in the server. Improved latency as well, where the server side execution of fetch or database operations results in better latency, as servers and data centers are typically geographically close, leading to faster responses and faster access to the data. And finally, we have UX and DX benefits. Most server components just have a better experience than traditional SSR, a topic which we will dive into shortly. On the developer experience side, using RSC, especially for data fetching, is straightforward. In earlier versions of Next.js, data fetching on the server side was limited to the page level. It wasn't possible to do server side data fetching on the component level. Now it is. Also, the process was a bit less intuitive, contrasting with the simplicity of using React server components. As you can see, this is a big chunk of code where we have something simple, seemingly, right? But then we have to do this entire get server side props thing as well. I'm guessing most of you are aware of that. Where now, we have something that is much simpler. We have exactly what we want, a typical React component where we have search parameters at the top giving us access to the data we need similarly to what we have seen before, but in a much more simplified code base and much simpler understanding. That's what the developer experience is all about, right? We can build great things and ship them in weekends, right? You've seen a lot of people just done a lot of great projects in short amounts of time because Next.js allows you to do all of these things right out of the box. Let's do a quick summary so far.

React server components are components that specifically run on the server side. They produce an RSC payload, which is essentially a server side representation of the entire virtual DOM, the document object model for a given application. This payload outlines where each component should be placed in the DOM structure and frameworks like Next.js come into play at this point.

They take the RSC payload and the HTML file generated from the server side, virtual DOM and send them as a package to the client, which is the user browser. Now on the client side, the browser reads the server side virtual DOM and starts constructing its own version. It adds necessary client side components to the tree as specified. And this process is called hydration.

It's important to note that React server components and server side rendering, SSR, are different concepts. While you can use RSC on its own, doing so requires manual management of various aspects, whereas integrated frameworks like Next.js simplify this process by efficiently handling both RSC and SSR for you. The SSR mechanism renders both the server side components using the JSON payload or RSC payload generated by RSC and the client side components, ultimately transforming them into the HTML code that represents the blueprint of the entire application.

We should consider using RSC for data fetching, anything security related or sensitive information and heavy dependency execution. Whereas RSC components, or sorry, RCC client side components we can use for anything that needs interactivity. And that's more or less it. I was moving to the next slide, expecting more things to come up, but no, right? We only use RCC when we need some client side interactivity. It is as simple as that. Now, what this all means, if we properly use their corresponding components for what we need. It means that we're going to reduce client side code. We're going to also improve security. We're going to improve the network latency. We're going to get optimized SEO and have a better user experience and developer experience, which is what matters to us the most.

Great. Now, I will cover the edge versus node bit in the end, as we're deeply into the SSR and RSC mechanisms right now, which is the foundation for this bits. But we learn that with client side rendering right here, we load everything and execute everything to show anything that looks like this. Everything is happening on the client side. Thus, our users had to stare at the white screen for a good amount of time. With server side rendering on the other end, we executed something on the server like this, and then show something on the site and then load everything to hydrate the parts that make the interaction. Much better, right? That sure improves the initial load times as we're showing something, a non-interactive thing at the start, but hey, they get something, right? So, this helps us to not lose a potential not so patient users or customers, right?

I can see some comments right here, improve security, how? Well, it's typically always better to run secure code on the server. As on the client side, things are easily exposed, right? I'm not saying that this is improving the security over the typical server side approach. I'm just saying that maybe it makes it a bit easier for us not to make a mistake of exposing some variables on the client side. Whenever you're doing some security stuff, whenever you're doing some payments, typically libraries and packages like Stripe don't even allow you to do a lot of sites on the client. So now, it just makes it a bit more convenient to call it on the server, and server being the components directly, right? Which makes it super easy to do so.

So now, it just makes it a bit more convenient to call it on the server, and server being the components directly, right? Which makes it super easy to do so. Now to address some of the mentioned issues, React 18 introduced two significant concepts, streaming and selective hydration. Streaming is like sending parts of a puzzle from the server to your computer as soon as they're created, instead of waiting for the whole puzzle to be finished before sending it. That way, the server delivers pieces as it makes them. Whereas in traditional server-side rendering, when a user makes a request, the server starts creating the HTML page, and the client has to wait for the entire page to be generated. After receiving the page, which is just the initial content, the client then downloads all the JavaScript and begins hydrating it. However, with streaming server-side rendering, as soon as the user makes a request, the server starts executing the components. The moment they are ready, they are streamed down to the client one by one, and this eliminates the wait time for the complete page generation before content is sent to the client. But what if there's a network issue? Well, think of it like a busy road. Network, right? And trucks being the data that can't move fast. With streaming, if the road is full, the server pauses sending pieces of hard data until there is space again. This prevents the server from getting overwhelmed, and your computer can continue working on the puzzle when there's room. And streaming enables your server to handle multiple tasks simultaneously, even when faced with challenges, your website remains quick and responsive. So once again, this is a feature introduced in React 18, and to use it, you'll have to use the Render to Node stream to stream your app content. As mentioned before, frameworks like Next.js thankfully have built-in support for this. All you need to do is grasp the concept, make informed decisions, and focus on the business logic. In essence, streaming server-side rendering utilizes Render to Node stream instead of Render to string, used in regular server-side rendering, to stream or send chunks of data as needed, rather than sending everything at once. OK? So server issues are not going to do anything to stop it. And also, once again, we see that Next.js uses really conveniently and in a smart way features that are built into React. It just uses them, and just kind of wraps them in a way that makes them easier for us to use. But still, don't forget, we have to grasp the concept to be able to make informed decisions.

So what's selective hydration in the first place? What do you think the hydration mechanism would be if we used streaming server-side rendering where we're sending content as they're ready? Wait for everything, and then start hydrating? That wouldn't be the best use of SSR, would it? With traditional hydration, we get the entire tree, and then React hydrates it, start to finish, only once. Well, now, imagine a child having a bunch of toys to play with. Before that child can start playing with any toy, he needs to collect all the instruction manuals for the toys. Of course, it's not really like this, but just bear with me for a second. Now if some manuals are really big, right, he'll have to wait until he gets them before he can start playing with any toy. Well, even if there are smaller toys with smaller manuals, he still has to wait for big ones to finish, so until he has all the instructions, he can play with any toy. This happens with regular hydration as well. But, with React 18 and streaming SSR, React hydrates the tree without waiting for larger components to be ready. That's what selective hydration is all about. A process where React hydrates the components or chunks it has received via streaming, rather than waiting for everything to be finished. It starts hydrating as soon as it has something to hydrate. But, how will React know? Well, it's simple. Wrap whatever you think will take a longer time to load with suspense. This tells React not to wait for this component to finish and to continue streaming and hydrating the rest of the content. So does the virtual DOM or tree on the server get generated again? What's the workflow here? Well, the process goes like this. We have to wrap the components that you think will take longer time to render, like this. We can also do some extensive calculations or operations and we just wrap that with suspense and we render the fallback that's loading. That looks like this. The client makes a request to the server, React starts rendering the React server component and building the virtual DOM on the server, and the moment it encounters the code where we're using the suspense, it'll use the fallback code inside of that tree and then continue building the rest of the part. Now, when the component is done doing its work, it'll stream new HTML containing the fallback code of suspense to the client, along with sending the script to show what has been replaced with the fallback code that has been rendered on the UI. It's not so easy to grasp, but the underlying mechanism is, of course, hard. To demonstrate the workflow real quick, let's open up the application I have over here. By the way, you'll get the complete GitHub code link in the description, or in this case, it's going to be in that Discord forum that we have. I would really like us to continue the conversation going on there, because we're discussing many topics that you cannot really find a lot of information for online, and I think that's the reason I'm doing this. With topics new, such as this one, maybe your employers have sent you, or maybe you have come on your own, which is amazing, to learn about how to use the latest and greatest of what makes us more efficient. Nowadays, you cannot find that so easily online. I know, because I had to dig through a lot of GitHub pages. There's no documentation whatsoever. You have to find it on your own. The fact that you're here right now, listening to this, it's just amazing. Just wanted to put that out there. The link is going to be there. What I was saying is, I would want us to continue this conversation on Discord, because we can all learn from each other even after this talk is done. Great. Let's go over this app really quick. We're going to create a sample app, sample component, wrapped inside of suspense. It's going to do fetch calls. It's going to do a lot of stuff. Let's dive into our second example of the day. I'm going to close this, collapse all the files, and just re-navigate back over right here. We're going to create our second example of the day by running mpx create next app. We're going to call it. Let's do something like hello-stream, as we're learning about streaming.

Excuse me, Adrian? Yeah, sorry. Go ahead. I am tempted to follow along as you code this, but I'm not sure if that was the intention. Yeah, I think it would be tough, but I would say we're going to have a recording of this. We're going to also have a Discord chat, and I'm also going to give you full examples of these repositories that we're creating. I would recommend maybe watching along, keeping some notes, which would be great as well, and then we can later on revisit them, and you can ask questions if you have any, while you try to replicate that later on. Is that okay? Yeah, thank you for clarifying that. That's great, no worries, Vanessa.

Let's also see. Let's see, so let's try to open up this stream, and what we can do is go into here. Give me one second, just trying to ensure that we explain this as good as we can. We have this HelloStream, and I want to ask for a second, I have my colleague here preparing also some files for me here. I'm trying to figure out what exactly we should show here. We also want to get to this tree that we talked about not that long ago, so let me just create a demo.js file right here, and essentially we're talking about this tree doing the loading. We want to figure out where we have this React suspense, but of course I want to figure out a way to get to that.

Instead of me writing the entire piece of code here, let me just open up, or rather paste a new folder right here, which is going to be called HelloStream, but rather the new one containing the code. Here we want to go ahead and proceed with the demo. As you can see, it's once again a simple page where we just import a component called.sampleSuspense. We're still rendering the component on the server side right here, and we have the main right here where we have just rendered the main, h1, html, we have a server component, and then we're calling the suspense right here with a fallback of a simple loading and then putting the sample suspense right here, which is calling our Pokey API, so it's doing an API call still on the server. It's getting us some data, and then it's showing that data in a JSON stringified way. Pretty simple example.

Now, what we can do is I'm going to navigate over to the HelloStream. Let's go to HelloStream copy, I believe, if it's going to let me do that. Let me just rename it to HelloStream 1, bear with me here. There we go. I'm going to navigate over to HelloStream 1, and I'm going to run npm install, and then I'm going to run it. And then we should be able to see a new folder appear right here, which is going to be a dot next. There we go. And now if we go into, I believe it's here, right? Server, and then we have the app folder right here. Let me see. I think I have to run the build right here. Yeah, so let me run the npm run build so we'll be able to actually see it in an example here. Yeah, there we go. And yeah, I also can see you're asking for the link of the repo. Yes, we're going to share a link. I believe it's public already, so my colleague will just pass it into the chat, and we're going to also have the full video, as well as the repo and everything else on the Discord forum later on. I believe it's going to be the best way to keep the communication. I believe somebody from Git Nation, Alexander maybe, has already shared the forum at the top. Yeah, yeah, I believe it's there. So now we have this server, and we have the app in the server because now we have built it. And then here, what we're looking for is, we have the page.js. And once again, it's quite hard to read, but if we search for suspense, you can see it's being used a couple of times, and we can see the code being generated right here. So it's rendering the children of loading, and then the second time, it's going to render once it's finished doing its work. It's going to give us back the data from Poki API. That's kind of the idea of this. There we go. So once again, we can see a wait patch. Yeah, I would like to show you the tree that's being generated. I would just have to find where it's generating that tree. Let me see. Yeah, so it's in the index rsc. And there we go. This is the tree right here that we can see, where we have the two React suspense. In the React suspense, we can see a couple of things. We can see the number two, which is the just React suspense. We can see the fallback right here, which is rendering the children of loading, which is, it has an L3 reference right here. And then, we can see another children right here. It's being mentioned a lot of times. But we have the second one, where it's actually rendering the actual content that's coming back. There we go. It's right here. It's quite easy to notice it because this time, once it renders it, we get the response from the API back with the count of 64 and all of the results right here. So this is how React suspense work. It's being sent as a script right back within index.rsc. And now, we can run the run dev, go to localhost 3000, and we should be able to see how that actually works. There we go. We have welcome to Git Nation. This is a server component. And then, we can see sample suspense component right here. If I reload, maybe we'll be able to catch it. No, I think it caches it. Once again, we're going to talk about cache a lot later on. But now, it's always going to be here, and we can see the entire thing. And it's going to be similar if we inspect it and go to elements, you can see that it's being provided to us right here in this script, where it pushes it later on. So we have script.push sample suspense component. And yeah, the code is being just provided to us here. It pushes it whenever it gets it. That's the idea of streaming, right? Let's see. So at the start, we see the loading. Then, later on, we see index.html, and that's exactly how the process is. Let me just go back from this example. And once again, all of these examples will be provided to you with the code, as well as within the chat and future information, maybe in the readme of each one of these examples. So we'll be able to dive into them, and I'll keep building on these examples as well.

We have a question as well. So basically, React dispenses some content and shows ready placeholders instead of them by the time the background trying to make them ready. And when they're ready, React just replaces them. That's entirely, that's exactly right, Halil. That's phenomenal. It's called streaming. You nailed the concept of streaming perfectly. We stream that content on the server to the client. React renders it, replaces it. And it's like nothing else has ever happened. It just works seamlessly. So that's our streaming SSR, the advanced version of SSR concept. Quite new. Not a lot of people know about it yet. So it's pretty cool that you're here listening to it.

Now there are two main types of SSR, regular and streaming. We just learned about that, right? Within Next.js, these types further break down into, of course, why would it have to be two if it can be more, a static rendering, which happens during build time of an application where pages are server rendered at build time. And it's like what we've been doing so far when running NPM run build, so far static rendering, also known as static site generation, it's the default strategy used in Next.js.

Now for dynamic rendering, this renders the application for each user at the time of their request. So whenever a user makes a request, the page is generated and sent to the client, dynamic, every time. A remarkable piece of feature innovation is that you can decide what should be static or dynamic rendered on page layout on a route level in latest Next.js. Doing that is super simple. As you can see, all we have to do is add this sort of flag in the page or route and Next.js will automatically show something differently. So there is this flag, route segment config, it's just a matter of providing the right config right here.

Specifically we can talk about cache, I know there's been some backlash for Next.js for not allowing us to properly specify what we want to do. Do we want to cache? Do we not want to cache? I think they're continuously adding new ways for us to modify the way that our content actually renders. So you can choose whether it's static, force static, force dynamic, auto, pretty cool thing. In this case we're talking about revalidate. You can force cache it, you can just leave it as 0 or a number in this case. But yeah, you can decide force cache if you don't want your content to update. But you can leave it as false if you wanted to revalidate for different users. Additionally, you can also choose the middle ground, which is keeping the static content for a while and then changing it afterward. This is known as incremental static generation. Initially, all pages are statically rendered during build time. After a set timer, which we can customize, the server renders the pages again and serves them to the client via a CDN. You can specify and opt for this feature using the revalidate of Next.js. We can just provide a simple variable of export const revalidate at the top of a specific route, and you can set it as a number. I believe it is in seconds. If you set something like 1,200, it's going to revalidate every 20 minutes. It depends on how dynamic you want your app to be and how fast. If it's cached, then if you don't need it to change, it's phenomenal. It renders in an instant. If you need to fetch new data every minute or every 20 minutes, you can specify exactly that.

Moving on, do you remember how we did data fetching in React Server Components? It was this. You simply specify it, you make the function async, and then you fetch some data, get it, and present it. That's it. Now, what if there are two or more requests that we have to do? For example, first, check if a user is authenticated, and then do the data call to get further information. A solution to this is what we call, yet another word right here, sequential data fetching, a situation where requests in a route or a page are dependent on each other. It's going to look like this. Imagine you have a series of tasks you want to complete, like building a tower of blocks. Sequential data fetching is like doing one task at a time, where each task depends on the completion of the previous one. It's like adding one block and then waiting for it to settle before doing the next. You might want to compare this with doing promises. You may do dot, then, dot, then, which is just one after another. We also have promise that all, which does all of them at once. I would say chaining the promises one after another is similar to sequential rendering. Sometimes this order is essential for cases like we discussed above. However, if we're not careful, you might unintentionally create a situation where you have to wait a long time before starting the next task. So while sequential fetching can be useful for a few specific conditions, it can unintentionally make things take longer to finish. And this phenomenon, in tech terms, is also known as a waterfall.

So how not to create request waterfalls? Well, there might be a case in which we want to make multiple requests that are not dependent on each other. How can we handle such a case without blocking the application? Well, that's where parallel data fetching comes into play. As the name suggests, it allows us to call multiple requests in parallel. Think of parallel data fetching like having multiple helpers to get things done at the same time. Instead of doing one task after another, all the tasks kick off together. It's like having several friends who work on different parts of the project at the same time. Although it might not be the best example as we might know that the more developers you add to the project it might end up taking longer. But let's not think about it this way now. So how can we do that? It's, I would say, simple. Yes, there are many things that we can do in XJS and that's why many people like it. Check this out. What we have here is an async function where we have sample parallel fetching where we get the params and then based off of the params which are still server side, we fetch a specific product by running the product.findById function and passing the params id. Once we get the, only once we get the product, right, can we find the reviews for that product. We could technically hold the two things at the same time, right? You don't have to wait for the product to be able to fetch the product reviews because you only need the id to be able to fetch the product reviews, right? So what do we do here? We chain it in a productReviews and we get the await promisehole. See, similar thing that I've been telling you about is how you might have been imagining it this entire time. You just put it in a promisehole where you get product and the reviews but it's so cool how they have done it. You pass an array of two different calls. Would you say this is more so JavaScript than Next.js? I guess that's a good question, right? Because we have all been used to promiseholes and I loved when it came out that it's so convenient to be able to use it right here within our Next.js application now.

So now we start showing both once the promisehole finishes. So we await the product and the reviews and we show both once we get the data for it. Now there's another thing I want to talk about really quickly and it's called preloading data. It's another way to prevent waterfalls is to use the preload pattern. You can optionally create a preload function to further optimize parallel data fetching. With this approach, you don't have to pass promises down as props. The preload function can have any name as it's a pattern, not an API. That's going to look something like this. We have a function, exportConstPreload that gets the ID and it simply gets a specific item and then we can call it right here. ConstResult is equal to awaitGetItem and it's going to get preloaded. I would definitely want some more information on this but as you can see and as I repeat myself, this is it. The preloading data documentation page doesn't have too much info. It's growing and we're at the bleeding edge right now. Not only of Next.js, but also of React. So sometimes we'll need additional examples from the creators of these features, digging deep into their GitHub pages, into their examples, code bases, and more to be able to learn it or we can keep discussing it as well in our Discord forum. So this was a lot of things to cover. We are trying to understand what React Server Component workflows are, client-side rendering, SSR, streaming SSR, different types of patterns, and when to use what, and all that. You might have a question. If we do direct fetch or db calls right here inside of the React Server Components, and would you want to have that same information in a subcomponent, then what would that way be? So this component makes a call to the server and how do we get the data here? In short, a question where would you like to share the same data across multiple platforms? Or a few components without turning everything into a client-side or leveraging the same features we talked about? The question of course, is it possible? The answer is yes. And how? You're going to hear me say that again. It's simple. We have to make fetch db calls again wherever you want. But of course, wouldn't that mean too many fetch db calls? Well, not if we're being careful of what we're doing. This welcomes us to another topic of the day, where we talk about cache. Typically, in the previous world of React or just JavaScript or some other programming languages, technologies, this would be so bad, making the same request to get the same piece of data from two different places. Double the API calls, double the network payload data, double the everything. Thankfully, Next.js abstracts yet another thing in this whole journey of abstracting things and making things better, and it does it through cache.

Before diving into cache, I want to make a segue here, and I want to get a bit of a pause to let us all read for a second. We covered an exceptional amount of data and information in this... I'm not sure how much time has passed. About an hour, right? Maybe even a unhuman amount of data that we definitely cannot process in an hour. So if you're going to get one thing from this workshop, I would want you to get just the idea, right, of all of this. Just know that it exists. Just know that maybe when you're developing an application in the future, remember that you've heard about this. Remember that it exists, and remember that Next.js most likely abstracts it in a way that makes it easy for you to consume and to actually put into your application. So don't try to kind of be bummed about not understanding or not properly even hearing all the things that I shared right now. It's impossible. So just be cool about that. Know that you're going to have all of these examples, demos, and everything we shared in a link. We shared it already in the chat. We're going to share it multiple times. We're going to keep building on those examples and take it slow. Just know that these concepts exist and then just utilize them when you need them by going to the documentation, right? I just want you to introduce you to these concepts, right? Not to teach them to you right now, right off the bat. It's impossible, especially on larger applications. So let's take a bit of a pause right here. Feel free to discuss it in the chat, most likely, and then we can take maybe a 10 minute break, and then we can come back and talk about even more new, cool features, continuing with cache.

Okay. Yeah, as I said, I try to throw in as many of these concepts as possible. My team and I have spent a lot of time digging into these features in the alpha and then beta and then now stable with server actions, with cache. It's tough, right? But again, the more you know about it, I don't want to give you some definite answers right now. I want to introduce you to topics and then you will be able to dig into the docs, but I want you to just know that these things exist. So let's take a bit of a break, and then we're going to dive deeper into all of this.

Okay, that's great. That's great. Yeah, coming back to cache right here. Cache is a topic that some people didn't really like how Next.js handled. Yep. Are you maybe one of those? Because Next.js seemingly, too much abstracted the way for us to handle cache. Some people say that they would prefer a bit more ability to manage what, when and how does it get cached? Okay. So now we're going to start right off with demo. And I'll give my best to show you that Next.js gives you a lot of possibility to modify the way that things get cached, maybe even too much. No, just the right amount. But not too many people know about how to modify it all. Maybe it should have been more obvious in the docs, but we're going to go through it together. So let's start with the next example right here. I'm going to just get the hello-cache folder right here, which we can together explore. So I'm just going to paste it right here. And it's once again going to be a typical Next.js application. And we want to ensure, let's first look into what we have here. Well, I'm going to run, I'm going to navigate to it, navigate to hello-cache. CD hello-cache. There we go. And run NPM install first. So we can nicely see it. And I'm going to later on run it. And I'm going to show you a little cool trick that you can do as well.

So first of all, right here within this hello-cache, let's talk about what this is even doing. Here we have a homepage where we fetch, once again, some data from the Poki API. We return it and we stringify it and display it. Pretty simple. In the layout, nothing too interesting is happening. And we have another fetch right here, which is a component, which is doing the same exact fetch. We can show it right here. It is the same exact thing happening right here. Limit 10, version 2, Pokemon, just give us the data and display it. But here you can see same fetch, and then it's returning it. And right now, we're not using this component whatsoever. It's just being imported right here.

Now what we want to do is we want to enable some loading right here. I want to enable additional logging options by Next.js. And there's a nice documentation page that looks like this. Again, something that not a lot of people know about. It allows you to configure the logging level and whether the full URL is locked to the console, we're running Next.js in development mode. So what we can do is we can enable this full URL load in Next.config.js by doing this logging part right here. So if we go back and go to Next.config right here, you can see that we have enabled logging full URL. So what I'm going to do right now is I'm going to run npm run dev to get our application running. And on localhost, we can see something that looks like this. It's going to be just all the data that we get back from the Poki API. And we get it right here, 200 in 2620 milliseconds. We get the request right here, and you can see the cache hits a skip right here, which is interesting. First of all, you never usually see this. You're only seeing this right now because we have enabled logging. And now what we want to do is delete the Next folder and then restart it again. We're going to try to see which routes have different things right here. And give me just a moment.

So this demo is just phenomenal. We have a lot of things going on. And as I said, we're at the bleeding edge right now of just caching in the way that Next.js handles it. I'm going to be right now completely honest, this demo was created for me by my colleague, Sujata. She's here as well with us. So if it gets stuck trying to explain some of these parts to you, she'll be able to just jump in and help us as well. Essentially we have this About page right here where we're doing the same exact thing as we're doing in the homepage. Two of the same exact pages. And we're doing, once again, the same exact call. So now, what we want to do is maybe also navigate to that page to see what's happening. We can do that really quickly by going to the About. So let me just open it. I think I have it open already, should be right here. There we go, localhost 3000. And we can see it right here. And we can also navigate to forward slash About. Same exact thing, right? But what happened right here? You can see that we get cache hit, which means that it found the existing cache, and then it hit it. Okay, same thing. And we have skip one more time because it also skipped it. So Sujata, which is my colleague right here, I want to ask you, would you mind kind of diving deeper into the way that we hit or skip specific elements?

Yeah, for sure. Hello everyone. So yeah, talking about the cache that is happening over here. Sorry for the pronunciation if I make something sound something different. But yeah, let's talk about this thing briefly. So what we are demonstrating is that in Next.js, instead of using some global state, context API, Rails toolkit or anything, which will turn our components into a client components, and we won't be able to get the benefit of the app server side RSCs. So what we do is that we simply make fetch calls in other pages. So for example, we are making a fetch call in a page and same data that we need in About page, we are just making that call over there. So what happens is that first time when you visit the page, the cache will be skipped. This is the first time we are making a request to that URL. But the next time when you visit any pages that are calling the same URL or making the same request that Oak API that we are using, instead of it is making call to that Oak API, it will use the cache results that has been stored by Next.js for us. So if we go to the.next folder over there.

That's pretty cool. So what's happening behind the scenes is Next.js created a wrapper for the fetch functionality and Next.js behind the scenes knows immediately that this call has already been made, no matter that we're calling it from a completely different page. And then it hits it and gets it from the cache. Is that right?

Yeah, that is completely right. And that's coming from here, fetch cache. And it technically generates this file. And it's quite hard to see, but you'll see it using Cloudflare services right here. There we go. Cloudflare. We can format it. I'm not sure how can I do that. Here. You can right click it and you will see a format. Okay, there we go. That's much better. I would need to configure the formatter. But yeah, I think this is okay. There we go. This is much better. But now, yeah, you can see that it's using Cloudflare as a server. And then it's caching the responses and sending it back to us. Right? That is it. If you see the end of that page, you will see the URL that has been cached. The revalidated time. That's it. And the revalidated is right here.

This is amazing. As I said, I wanted to have Sujata here as well. It's so crazy that even myself trying to create all of these educational videos, it's so hard to stay on the bleeding edge of technology. And I wanted today to provide you with the latest and greatest of everything we are doing right now. So all of these demos have specifically been created for you today to be able to go over them. I think this allows me now to quickly go back into the presentation right here and show you a bit more. So we talked about this already. We have a lot of stuff. We want to cache specific things. Right? So Sujata, we talked now about fetch cache. Do we want to kind of keep talking about it or do we want to dive into some other caches as well?

Yeah. I mean, the basic question that I think we would have is that there might be a case that we want to fetch or use fetch all the time. Yeah. So the question arises that what should we do or how we cache the content or how Next.js measures that if we don't use fetch. For example, we just want to directly make the TTP calls inside of React components. So we cache or not. So for that, we have our next thing, which is called React cache.

I think it's a hit. Yeah, that's correct. So we have seen this all that. And it's so easy because we, once again, Next.js makes it amazing because we don't have to do absolutely anything. You simply have to use the basic fetch call. And that's it. It works right off the bat. And you can also set a timer and tell it to revalidate after a specific time. So here we have time based. You can revalidate the fetch calls after, for example, this is 3600 seconds. So you still have... Because some people are confused. Think about it. For example, we never explicitly told Next.js to cache anything. And still, it did. Which you as a developer might think, why are you doing things for me? I don't know when you're going to cache it and when you're not. What if I want to get my data fresh? So thankfully, we can still revalidate the data after a specific amount of seconds. We can also revalidate it on demand. We can extend the Fetch API to decide cache revalidation depending on your specific needs. And there are two ways of doing this. The first one is the Revalidate tag. So you can add this Revalidate tag to the Fetch call, Next tags, and then say what you want to revalidate. Specifically once you make this API call. And then you use it like this. So we go to the new server. This is a server action where we import Revalidate tag from Next cache. And then once this happens, you want to revalidate that specific tag of posts. We'll see how we use this in the new server really shortly. That's exciting. Then there's also Revalidate path right here. Similar to Revalidate tag, but we have to specify the path that we want to revalidate and then have fresh data. So in this case, we can revalidate posts forward slash slug, which would be a specific post ID after maybe you change the post data. And you can find further ways in which we can revalidate pages, routes, and more in the Revalidate path documentation on Next.js. So now we have learned cache and how to revalidate it. But there might be one doubt that you still have. You might be thinking that, can it be cache only when using fetch? That's the only thing we have done so far. What if we don't want to use it and rather we want to do direct DB calls in React server components like this? Where is the fetch here? Nowhere. We're using Prisma, right? To just do a regular fetch from the database. And any other third-party solutions, we can use React cache to cache these requests. Let me show you how to do that in a simple example. I'm going to open up, once again, our codebase right here, and I'm going to give us maybe the fourth, I believe, or yeah, this is third, maybe, or fourth, example of the day. We're going to call it, hello, React cache because no longer are we working with just fetch cache. Here, we have our app. We can, of course, navigate to it as before by doing cd, and then navigating over to hello, React cache, and running npm install to get us started. Right here, let's first visit our page as we always do. Here, we're calling two different things, with cache result and without cache result. These are just some simple utility functions that, if we go into them, generate a random number and then, if we don't cache it, that's going to look like this.

We're going to simply set this variable to that specific random number, or rather to a function declaration that's going to fetch that random number, and then here, we cache that response coming from React. Keep in mind, this is a basic React functionality. We cache that function declaration. Then, we call them right here, and we just display them. Random number on home page with cache, and without cache. Let's kind of see how that works. Same thing here. We're also calling them in a sample server component. This is server, and this is also server here. We're calling it in two different places so we can see exactly how that's going to work, and why and where are we seeing this server component? It's going to be here. We display it once normally, just in the regular page, and then we display the same thing coming from a different server component so we can see exactly how it's going to cache the data right here. We're also doing the same thing in the about to, once again, figure out how is it caching it. Let's kind of run it and see what happens. I'm going to run npm run dev, and open it up on localhost 3000, as we usually do. Everything should be visible here. On the page, random number on home page with cache is 91. Inside of the component, the sample component, the sample server here, it's 91 as well with cache. Without cache, we get 6472. If we refresh, we see a new number with cache, 38 and 38. What's happening? It's not a bug or anything, it's how React cache works. It doesn't cache the results across routes, but it memoizes the request routes we'll make inside of one page.

Let's dive a bit deeper into the topic of request memoization. What is request memoization? Well, it's a tactic where if we're sending many requests across various components within a single page or route, some of which are identical and some of which are different, React cache ensures that these requests are memoized. This means only requests are executed. If the same requests are made in different locations, instead of making requests for each one, only one request is sent and the data is shared among the components that initiated those requests on that page.

Once again, imagine if you have that magic helper that can fetch things up for you. With React magic, if you ask for the same thing but different parts of your application, so even if it's in different places, it's not going to fetch it every time. It's going to try to get it from the cache. In simpler terms, let's say you have your favorite snack, and if you want that snack in your room, your living room, and your friend's house, you don't need to go to the kitchen every single time. React helps you get your snack wherever you are without fetching it from the kitchen again and again. This is handy because you can get the same information in different parts of your app without worrying about making unnecessary trips to get it, which makes things faster and more efficient.

However, this occurs at the route level. To show, if I create another page with identical fetch calls, we won't observe the same outcome for cache data as we did on the homepage. Optimization only applies to that particular route and the components within it. Okay? So what if you have things like fetch persisting the same data across the application? Well, Next.js has got you covered. Although the team is still working on it, like on many other things, you can use something unstable underscore cache to cache your requests across the routes, and here, we can greet or say hello to unstable cache.

So let's quickly spin up a new project right here. We can close this one. I think we covered pretty much everything we wanted with this one, Sujata, right? The way that it caches it across routes. Yeah, that's the main thing about React cache. That's it. We have seen first just general fetch cache, which caches the fetch requests. Then we can see, we have seen the React cache, which caches it across routes. And now we can welcome the next one, which is hello unstable cache. If I can put it right here at the root of my directory. There we go. That's another topic we can dive into. So as usual, let me just open it up. I did want to provide you with real demos, so it will take some time but hopefully we'll be able to go through it. There we go. And we want to run it and install it. In the utils right here, the app is still really similar, right? We have the same thing as before. We're just building on top of the previous example, where we have the get data with cache, get data without cache. And then now in the utils, we have added get data with unstable cache, where we wrap the function declaration of get random number. I see a typo here, but we're going to fix that. We're going to wrap it with the unstable cache coming from next forward slash cache. Pretty new, pretty exciting. It's just a simple function as you can see right here, but it does wonders. Now, what do we do here? We are adding it to our previous calls. And similarly, we have it in our homepage, we have it in our sample server page, and we also have it in our about page. Same thing as before. We're importing it everywhere. So what if we give it a go? What if I now run npm run dev and try to test it out? What do you think is going to happen? On our homepage, we get with cache 22 and of course it's cached on that specific page. With unstable cache, it also remains, in this case, generated as 75. So now if I reload once again, and if I keep reloading, you're going to notice that with unstable cache, it remains as 75. Similarly if we switch to another route right here, if we go to forward slash about, you're going to see that with unstable cache is once again 75. Same result that we've experienced with Fetch Web API, but this time, it's across the routes, not just in one route. And though the name unstable routes might suggest instability, next.js team is actively developing it and it's going to be released really soon. So once again, if we go to the slides really quickly, can you use it in production? Right now, proceed at your own risk, right? But hopefully soon enough, next.js team is going to get it ready. In fact, the vice president of Vercel right now uses it on his website in production, and we can see the code right here. Pretty cool. That's a clear signal that it's becoming more and more stable and reliable. But let's kind of finalize this example and just round it up. What have we seen this? What does this even mean? We have a lot of different things, but the unstable cache seems to just remain all across the entire application. Is that a good thing? Is it a bad thing? How do we modify it? So Jada, what would you say here? What is the kind of takeaway of just fetch? We know fetch. It's only when we use fetch, and then we have just the cache and then unstable cache. What is the takeaway here between those two? Yeah, I mean, the first thing that we should understand is that React Cache just caches the request for that page or that route that we are using. But what we get with unstable cache is the result that we get with any normal fetch calls or fetch requests that we do. So there might be a case that we would want it, but again, there might also be cases that we wouldn't want these scenarios. So we have to make a first understand what we want. So for example, you want to build a blog website, you might want to cache these things, all these things. So you won't make the request to the main server again and again, but instead rely on next year's CDN networks. So this is where you can use either unstable cache or the React Cache. But yeah, the whole point of it is that doing this, we don't have to use or manage any state management libraries like context API, Redux toolkit or anything. But do note that it doesn't mean that next year's is replacing them, or just telling them that do not use them at all. There might be cases that will still need them. Without that, you won't be able to proceed. If you understand this caching mechanism and just keep on making the calls, considering what is happening, then you are good to go without the state management library in next year's applications. That's correct. But would you say it's making such a great progress with giving us the developers more control over how cache is being handled, whereas it wasn't doing that as soon as next year's 13 was out? Yeah, I do agree. I mean, if we have to cache anything normally without next year's, it's a very hard process. You have to set up the CDM networks. You have to manage them, all the infrastructure, everything. But yeah, thanks to next year's and Vercel infrastructure, all you have to do is focus on the business logic. You don't have to worry about anything else. Just understand the concept and trust on Vercel that it will handle all these cases for you. Yeah, it does make the development of the TX very good. It truly does. Let's kind of summarize it one more time. Cache is a special memory storage mechanism used in computing to store frequently accessed or recently used data, allowing for faster releases here. It's going to allow us to retrieve it much faster when the same data is needed again. So next year's has built in support for cache mechanisms with the help of react features. Once again, they don't clash. It's not like saying, you know, react has it at all, or react has it as well. Right. It's about merging the two and allowing us to use it with the next year's as well. You saw that, for example, for fetch requests, next year's just wraps it. Whereas for react cache mechanism, it just uses it directly from the import is coming directly from react. And then for unstable cache, that import is coming from next year's might seem a bit hard right now, but I hope that things will be a bit more streamlined down the line. So next year's extends the native fetch web API to cache all the fetch requests automatically. We can opt out of that automatic fetch request caching by providing the no store functionality.

So this is, first of all, a very good step on next year's aside, some people found it annoying because they didn't know when things will get fetched and when they wouldn't. But thankfully, we now have this cache no store as well, as well as many other options. We also have two other ways to revalidate in next year's. We have this next revalidate, which is the amount of seconds of when it's going to try to refetch it again. And then we have also on demand, which is great. It allows us to revalidate a specific tag like in this case, where we can revalidate the tag of posts and then recall it in a server action. We also have a revalidate path right here, where it's going to revalidate a call to a specific path. We can also use react cache to cache any third party solutions like Prisma or any calls that are not fetch related. And we can use next cache to cache the data across the application. Do keep in mind that the discuss revalidation isn't limited to fetch web API. You can use the same time based and on demand cache revalidation techniques with react cache or next years is unstable cache. And there are two powerful strategies to help us optimize data fetching and reduce javascript bundle size. There is the data cache right here coming from next cache, and there is the request memoisation using the request cache. So it's about figuring out how to use all these together that will allow us to truly be able to not be mad at the fact that next year is caching some things that we don't want to. But rather use cache as a way to optimize the data fetching of our next year's and react applications.

To be completely honest, right now it's a bit all over the place, the way that they wrap the fetch, which we're not used to, right? Because we use fetch every single day. And we wouldn't just assume that this fetch we're calling is different from the from the regular JavaScript fetch, right? That's one thing. And then also the fact that we have to call the unstable cache from next or the react cache from react. Right now, I don't like how it's currently structured. But hopefully things are good, things will get a bit more streamlined with cache in the future.

So although we did explore or actually use it before explaining it, I want to talk about talk a bit more about this properly. Do you remember when we use the user server instead of utils before for demonstrating the cache? I want to ask you how many of you have used user server before? Or server actions or with the next years in general? Have you used it? Okay, that's interesting. The user server is a directive similar to user client. And I can see more nos than yeses. But you might have had a gut feeling what this is about to symbolize. It's something about server things, right? Normally, they're known as react actions, or react server actions. These are simple, asynchronous actions that run on the server. That's it. But why do we need server actions? And let's talk a bit more about about them. So once one more time to explain, we use the user directive, we add it to a typical JavaScript file, and all the code that is in there, you can write as regular JavaScript code. But it's going to be rendered in the server. That's it. Does it make sense? So it allows you to provide more simple JavaScript code, but you run it directly in the server. But the question is why would we need to do that? So I wouldn't say it is a replacement, but instead it is an option to do mutations over traditional route handlers. We can use these server actions in both server and client components, which makes them a handy feature to use. While Vercel might be inclined to showcase the use of this feature for form submissions or mutations, we can use them to query things as well. If you aren't convinced yet, let's see a quick demo and we'll see how useful and handy they are while building an application.

We can create and use server actions in two ways. In server components where we can add the directive right here, use server directive at the top of a server component, inside of any React component for that matter, and we can make it async like this to turn it into a server action. So this is a typical server component where you can create a new async function create where you use server. The code inside of here is going to be rendered on the server of course. Why am I showing you this? Because we can also use them within client components, which is what makes them special. The way of using server actions inside of client components is a little different. Inside of what we did in the server component, we now have to create a new file, declare everything inside of it as use server and then import these functions inside of the client components like this, where we have a new file, use server, create and remove, and then we can call them whenever we need them to be, be that client component or server component. Such as in this case, as you can see, we are importing create from actions and we know that it is a server component. In this case, I think I forgot to put it at the top but it should go without saying, right? We're using state here, which means that this form is a client side component. But the key takeaway here is that we can still use the server action right here, okay? So we have the await create and we call the server action, the handle submit, and then we have the rest of the form, right? What this allows us to do basically is pretty crazy. It allows us to make a server side call within a client component. Is this clear so far? I don't want to proceed if this concept is not clear here. It's a bit counterintuitive because even though we have a client component and all of this code here is client, keep in mind we're modifying the data, right? We're modifying the form, the fields and everything. We can still call a server action right within it. Does that make sense? Okay, it does, which is great. Now you might think it's great, you might think that it's unnecessary, but let's kind of explore why we might need to do that. That would allow us to not create any additional APIs to perform any normal CRUD actions. In this case, server actions got you covered. Next.js has made things that simple to do. But you might think, how do they work? And how are we able to call a server component, or sorry, a server function inside a client component? Think, how is it possible? Well, there's no rocket science here. Server actions we use in client components are basically turned into a POST request by Next.js for us, okay? Any kind of server actions, be that getting some information or adding some data to the database, updating it, deleting it, Next.js calls our server through a POST request, but that is only for server actions inside of client components. So Next.js kind of once again abstracts it and makes a server POST request for us from the client component, so it's still in the server. And I can see a question by Halil right here about the concept of using the use server. It's for server actions, that's correct, and it's for differentiating between client-side and server-side code. Yes, that's entirely correct. So we use the use server directive as we would use the use client directive. We put it at the top of the file, and whatever we write in there is going to be executed on the server. Back to our example with the form right here, if I have to go way back, but if we didn't put the use server directive right here, it would render it on the client-side. I think I anticipated your question here, but isn't it by default server-side files? Do we have to specify it? Well, Halil, if you didn't have this use server directive right here on these two server actions, and then if you called them right here within your handle submit, where would it be called? What is this code? Is it client-side or server-side, right? So by default, it wouldn't be server-side, because we are within a client-side component called form. Does that make sense? Yeah, I would like to add something over here. So initially this was React architecture. Initially, they wanted to separate client-side and server-side through file-based architecture. So if you write inside a name that this is a server dot ts or js and that data as a server component. But then these flags started as a more initiative way of writing server and client-side code. For sure, for RSC, you don't have to specify these because that's what Next.js uses by default. But for anything that you want to do on a server-side, just use this flag. So even if you use this for RSC components, I think they should work as it is, because they are already using it behind the scenes. Exactly, exactly. So in cases where you, if you were to use this within a server component, then Halil would be right. It would be on the server by default. But if this allows you to call it within a client-side component as well. So exactly. Yeah, you said it's like holding the tool in the data. So you play it there if you use the user server. But if you don't specify it you get the tool and play it in the client side. That's entirely correct. Yes. So I'm really happy that that makes sense right now. So let me quickly go back to where we were, which is right here. Getting some data, uploading it, deleting it. And yeah, Next.js makes a post request right here. Let me see. So for server components, everything is on the server. And we just finished how things are being done on the client side, right? But now we want to discuss how things are being done on the server-side. For server components, everything is on the server. So the component and server function and everything is executed there. And then we get the HTML as a streamed response. So let's create a small application to see the server actions in demo. Which is where, once again, we're going to get back to our code and create a new folder right here. It's going to be called Hello Server Actions as we're just getting introduced to them. Once again we want to cd.., cd into hello server actions and run npm install. And let's see what do we have in store here. We'll create a complete interactive server-side form using HTML that works even if JavaScript is disabled. Yep, that's correct. We have it right here. It's just a regular HTML file form where we have an action of handleSubmit and we have two different inputs and a Submit button. Cannot get simpler than that, right? Once we call the handleSubmit, we're going to call this async function helloSubmit that's going to take in the form data, check this out, it has the user-server directive, and then we get the data, we form it into an object, and we simply console log it. We don't do any DB operations here, but you could if you wanted to.

Now, this works even if JavaScript is disabled because all of this is happening on the client-side form right here. As a matter of fact, we can test it out. For showing if a form submission process or not letting the user keep clicking on the form button while it's processing, we can then show the form status or disable the button while a request is being made. So to do that, let's go to another page and let's create the same form right here. We have the interactive and we have the normal, okay? In this case, we want to go into, let's check out the normal, here we have the loading state, as you can notice, we create a form with two input fields and a submit button. And when the form is submitted, the handle button will be called. We can use the states or use form data to get the form values as we do here, and that's it. Similar example as we had before, but now we're actually modifying the loading states as well as the error states and the disabled state, okay? For these, of course, we have to use the state. And of course, we have to make the component, the use client component in that case. This of course wouldn't work if we disabled JavaScript then, right? Because it wouldn't be able to get all these values, loading states and more. And finally, we have the third example, which is the interactive example right here. And I think I missed to show the action TS right here in the normal where we just submit the form, which is a server action that submits the form right here. Let's dive a bit deeper into this, Sujata. How would you explain the way we're using it right here, the handle submit? Yeah. Could you go back to the main page file? Of course. Yeah. Over here, if you notice, we are not doing any kind of server side or, sorry, client side things. It's purely a server side form. And even if you disable JavaScript, that should work. Yes, we can maybe test it out, right? Yeah, we can test it out. Yeah. Just to show it, I think this is a really good example to explain how the client side and server side stuff works. So if you go right here, and if we just go to inspect, I think we should be able to just try it out and send it. So let's do Adrian and let's fill it out. So if I do this, I believe we're cons logging it. There we go. We can see it right here. What I could do is I could also disable JavaScript. I believe I have to go to here, right? Sujata, do you know where it is? Yeah, preferences. Over here, if you scroll down, there should be a disable JavaScript option. Yeah, I don't use that too much. Let me just go through it. I think it should be somewhere here. Is it all the way down? Yeah, all the way down. Okay, there we go. And then disable JavaScript. There we go. I don't use this too often. I believe none of you maybe do. Or maybe your boss has made you test your web applications, even if JavaScript is disabled, which is not happening often nowadays. But still, it's good to check. If we do it, I don't believe I have to reload. But I can, I guess. So if I reload, JavaScript is definitely disabled. And now I can just do a test. And you should be able to see that it gets processed normally, even without JavaScript. Now, on the other hand, if we go to the second page, which is the normal right here, so that's going to be normal, the way we're used to doing things right now. Here, we should have some disabled states and loading states as well. And if I do the same thing once again, we see submitting, which is pretty cool. And we cannot re-click it if it's submitting it. Cool thing, right, as interactivity. But if I disable JavaScript, I don't think it did too much. Let's check it out once again. Yeah, it didn't do anything. It didn't submit it because it cannot without JavaScript. It doesn't know if this button is disabled or not. And it cannot call this thing right here, which is handle submit without JavaScript because it's using states, of course, in this case. What we can do is, oh, you're right. We can also go back and I can check the client-side code right here as well because we are on the client-side after all. If I go back here, and if I go to Next.js, if I go to forward slash normal, and if I open up the inspect element right here, go to console, and do this. No, nothing. And then even if we go to our, once again, I have to disable in here as well, preferences, disable JavaScript. Not sure if I have to reload. I'm just going to do that anyway to be sure. And if I now type it, no, absolutely nothing is happening. We get absolutely nothing in the client console as well. So it just stops our app from working. Now I want to also- Yeah, there is a reason for that. Yep. Just to clarify the question, it's because we are using that console log server-side. So it will never go to the client-side. That's correct. It's happening right here. And then we use the handle submit, and we use the submit form. And the submit form is actually using the use server directive. So that's the reason, we try to submit it to the server. That's the idea. And this then disallows it from happening, and this will disallow it from showing up on the client-side. On the other hand, we are coming to the latest example, which is the interactive app right here. So we are under server actions app interactive, where we have a page right here. Let's go ahead and explain it. So this is a demo to show how to do loading and error handling with server actions within a form. We have a function where we have the same form as we had before. We have the form that calls the handle submit, and this handle submit is a use server action where we get the data, and then we wait for a few milliseconds to simulate a slow server. Two seconds right here, and then we console log it. How is this different from the first example, Sujata? Why would you say this matters? Yeah, over here we are, I mean, if we see the first page, over there we are not showing any kind of state on what is happening when we click on the button. It is submitting, has it submitted anything. But here we have a special button, right? Yes. Yes. So this button, check it out, is using the use client state.

Or rather using the use form status coming from React DOM, which is pending. And then if it's pending, it is disabled, and based off of that, we can set the submitting or is submitting. So we're using a client component within a server file, which is a form, and this form is using the user directive to submit it back to the form. Is there anything you would like to add with this example, Sujata?

Yeah, I would just talk about that custom component button a bit. The use form status that we are seeing over there is a new type of book provided by React basically, which keeps tracks of the last form you are submitting. And depending upon that, it shows the state, whether the form has been submitted, successful, unsuccessful and everything. And we get that by that pending that we are using inside that button file. Pretty cool. But even if we didn't use it, we would be able to just set a use state field, right? Or in that case, would we have to turn our form into a actual client-side form, right?

Yes. And that is what we did with the normal route, or the normal page. And then it didn't work without JavaScript. Yeah, we can test this now. Whereas in this case, using the React dom, using the use form status right here, if we go back to our current application, let me just open it up right here. And if we go to, I believe it is interactive, same form, right? But now if we enter it, and if I do it like this, submitting, we saw the state, right? You saw the state. And if we go back right here to our code, you can see that it actually submitted it, nothing crazy, right? But if I go here, and if we go to our preferences and disable JavaScript right here, there we go. Reload the page, and then test it disabled. Let's say, disabledjs.gmail.com. And if I click submit. Okay. You don't see the loading state, but what we do see here is the new message. So even with the disabled, we got it through to our server. That is the idea. And that's how we can use all of these different states from React, and how we can use server components. Okay? Similarly, we can do similar things with error management, right? We're using another special hook from React hook form called use form state, which is what we have seen right here. It's not only for depending states. It allows us to handle error management as well. I can quickly pull up our use form right here, coming from the official React docs. You can see that, I believe, I'm not sure if it's ready yet. No, it's not. You can see that it is still in progress of getting there, but it allows us, pretty soon you'll see it all across the page, right? It allows us to just get the state and the last form action of that specific hook, and then we can use it, or of the form, sorry, and then we can use it and based off of it, we can do some future changes right here. Okay? I think that's more or less it when it comes to this example of server actions. Let me quickly see. We have used only a small example here, but it is such a powerful feature, and you're absolutely free to do any kind of complex scenarios using these server actions. To show you what I mean, let me open up the repository of my Next.js course. In this course, we cover querying, and complex mutations, and a lot of other stuff. This is the repo that I have right here. Let me just pull it up right here, so you can see it. Here we go. Let's go into where we're calling these server actions. I believe I can press the dot, and it's going to open it up directly in our editor right here. That way, we'll be able to more easily see what's happening. We dive into tasks and fetching recommendations, or conducting global searches. A lot of stuff will be happening here. Let's dive into our lib actions, and you can see for all of these different types of actions, I have created a new page, and we use the use server directive on the top. This is a production example of a proper way to use server actions. These are pretty hefty server actions. As you can see, we call the exportAsync function create server. We connect to our database, because it is a serverless architecture. We get the params. We make a modification to the database, and then revalidate the path. We're using a couple of concepts we discussed so far. Pretty cool stuff. The way we use it, of course, is let's see where, create answer. We call it right here. Within the answer file, which conveniently in this case, is a use client component, but we can call the create answer, or get answer, or any other async server actions that we have created. That's the power of these server actions. Now, quickly going back to our code base, or to our slides right here, pretty cool stuff what Next.js allows us to do with those. There were a couple of concerns or issues about using server actions. Thankfully, server actions, first of all, the first concern was that they were not stable, but then they became stable as of Next.js 14. There are a couple of things. Let me see where I am right with the slides. This meme was the largest meme of the Next.js 14 conference. It was trending all over Twitter and Reddit, where we have a function bookmark that returns a button, and within a button, we use a form action that calls SQL directly within it, directly within the client side code. People got a bit confused, thinking SQL is now directly inside JSX. Some even remembered their PHP days and started making fun of it. Like I mentioned earlier, it's not actual code that's inside of the component, even if it looks like it. Next.js will turn it into a POST request behind the scenes. When it comes to security, you can use anything inside a server action to check the input first before making actual DB operations. Here I have an even example of doing that. We're doing an example where we check the schema of the name and the email, and only if we validate the fields and if they're safe to parse, only then can we make any calls, right? So you can still make them secure. You can also add as many security measures as you want to make it safe. It's completely in your hands. And while server actions might be cool thing to try, and they are, there are some drawbacks, too. First of all, you can't use server actions for cross-platform development, where you need the same back end or same API on different ecosystems, like mobile or desktop. Server action endpoints can't be exposed as of now. So it's not like you're creating different API endpoints that you can just reuse across different front-end applications. Server actions also can be used for scenarios like webhooks or sockets, because in these cases you need a server always listening for event updates, which server actions don't support since they're an integral part of the server and are not exposed. Also, testing might feel challenging with server actions because you can't use tools like Hostman and testing has to be done directly. On the positive side, it does enhance security since your API isn't exposed. And for some, using post requests or events like updates or deletes may not align with best practices of HTTP protocols. Okay? Overall, it's best to use them if you want to build and ship applications faster. That's where they shine in improving the developer experience. And I've showed you the example right here, not this one, but the much larger one within our course where we have a huge application and we use server actions to just simplify it. Because instead of creating many, many different API routes right here, we do have some, right? But we don't have many, because we have opted for using the server actions to interact with their database instead of creating many different API endpoints. That's why we like them. They improve developer experience. Make writing your code seem like writing normal JavaScript, a normal React, whereas you're really interacting with the database within these functions. There's more topics to talk about. And the next topic would be, if I could get right in here, Edge versus Node Runtime. It's going to be one of our last topics for today.

But before I proceed with it, I do want to give you some more time to get a pause. So we're going to pause again for about 10 minutes, 5 to 10 minutes, and then we'll be right back to finish it off with Edge and Node Runtimes.

Just a quick intro. I don't want to dive too deep into it because I know that it's impossible for you to keep your enthusiasm, first of all, if you had any at the start, but to keep your focus for two to three hours. These workshops are great, especially if they span across the entire day. But like this, it's so tough to just get everything in, which is why, again, why I want to emphasize the point of just revisiting these examples and revisiting the presentation as well.

So I'm going to share with you, most likely, a Figma link to this entire presentation that you can visit later on. We're going to talk about Edge versus Node Runtimes. So just about figuring out, once we ping our servers, which server are we going to ping, how far away from us is it and how fast the response time will be.

So it's nice to see you guys. I see you also on cameras now. And I'm glad you're back with me right now. So can you all hear me well? Ready to hear, ready to proceed? Yes, sir. Amazing. Amazing. Awesome, guys. So after two and a half hours, guys, I thought this is going to take a bit less, but you're still here. Once again, now that I revisit this material, it's almost like incomprehensible in one sitting. So I apologize in advance and then right now for cramming it up with so much information, but just wanted to put everything in here. I can send you the presentation. I can send you the examples as well. So you can later on look at them and then review them and even ask questions from Discord. So just wanted to provide as much as possible here.

With that said, I want to talk about edge versus node run times in Next.js. But specifically here, I want to dive into another code example. So what we can do here is I'm going to provide you with another little folder, which we can open up right here. There we go. It is called hello-edge and we can once again, just dive into it by cding into hello-edge and running npm install. Or maybe I know that Yarn is more popular nowadays. I might transition to Yarn really soon. But let's see what do we have here. We have a page and this page is just typical Next.js page. It didn't change it too much. But what we can dive deeper into is the API folder. So now we're not talking about server actions. We're talking about Next.js API endpoints and the way to expose them. And I can see Achilles saying that it's good to hear about all of these different things. And now we can choose which topics you want to go into deeper, which is good. I'm really glad you found it that way. Let's look into the node right here. This is a typical API route, route.js under a specific folder, where we import Next.js response, we create an export async function get, and then we purposefully delay the response by one second. So we just await it. We await it, and then we return the response. Hello from node runtime. That's the first example. The second one is getting it from the edge example. Again, same exact thing. But the only thing you have to do is export const runtime edge. Once again, Next.js makes it so interesting and so simple to modify a huge factor like this, like changing the runtime, by simply running export const runtime, and then modify it. Okay. And then finally, we have a dynamic node, which we're going to dive deeper into. Again, just another little flag that you add old force dynamic on the dynamic flag right here. So now we would definitely want to deploy this application. Let me see if I can quickly pull up a photo of a deployment of this app. I think I can get it right here. There we go. You should be able to see it if I can quickly drag and drop it. There we go. So this is, if you deploy your application, this is how it's going to look like on Vercel. You can see we have Next.js, you can see static assets right here, and you can see different functions. Specifically, if your API is deployed on edge, you're going to get this edge mark, this edge icon right here.

Now, I didn't explain anything about why we might want to use different runtimes and how do they actually work. So let's get a bit deeper into that. What I might want to do is, let me first pull up my presentation right here, and then dive into that right from the example. We talked about a lot of rendering strategies, right? We talked about static, dynamic. We also had the environments, the server, client, node, edge, a lot of things was happening during this two and a half, three hours. And a lot of things is happening in Next.js as well. But specifically, we can see when talking about runtimes, that they have something to do with the server. Where is this server targeting? Is it targeting node or is it targeting edge? And let me tell you a bit more about both of them.

In this case, edge runtime is like having a mini computer close to where you are or where your devices are. So instead of doing everything on a far away big computer, it does some tasks nearby. This makes things faster, especially for stuff like websites, smart devices, or anything that needs quick responses. It's like having a helper right next to you instead of calling someone far away for every little thing. So when I say node, I actually mean node.js runtime, right? So how does edge, which is Next.js's Vercel's runtime, compare to node.js runtime? Well, let's compare it. First, let's start speaking about a location. The edge runtime runs at the edge of the network, closer to the users, whereas the node.js runtime runs on server clouds, or servers cloud, sorry, and local machines, so it can be run anywhere, typically on a server. And nodes, like Node, have their own unique purposes. Edge runtime is specialized for quick and efficient execution of code in distributed locations. So it's distributed across the globe. Whereas node is general purpose runtime for executing JavaScript code as we all know. Further differentiating it, we can talk about implementation. built on high performance V8 JavaScript and WebAssembly engine, whereas, on the other hand, node.js is widely used for server side scripting and development. And talking about use cases, edge runtime is geared towards low latency, where we want to just deliver the content really fast and quick and process all of the tasks near where our users are located. Whereas the node runtime is versatile for a wide range of applications, from web servers to command line tools and server side JavaScript applications as well. So while there are specific use cases for both, both have limitations. Here are some limitations of the edge runtime. It's a constrained environment, which means that edge runtimes are often more constrained compared to full server environments, limiting certain capabilities that we want to use. Latency is also reduced because they may limit range of applications compared to more general purpose runtimes. And then dependency on network.

And then dependency on network. Since edge runtimes are distributed globally, they depend on network conditions and issues may arise in network disruptions. Whereas limitations of node runtime is potential cold starts because serverless implementations of Node.js may have cold start times, causing a slight delay when a function is invoked for the first time. Resource consumption, where Node.js is a lightweight resource consumption, can still be consideration, especially in scenarios with limited resources. And finally, less ideal for ultra low latency. Where you need ultra low latency, the centralized nature of Node.js runtime may introduce some latency compared to edge runtimes. So we have figured it out. Both have their advantages and disadvantages. And if I have to suggest something, then I would suggest do things depending on your needs. Vercel, who has built its own edge runtime, shares a nice difference between all of these features and which features do edge and node support in next JS applications. So here we can see that again, you have to figure it out for your own, depending on which features do you need. Are you worried about security? Then you might want to use exterior securities high in edge environments. Are you worried about latency? Then and if you need really low latency, you can get low latency in edge. But on the other hand, if we look into let's see, NPM packages, all are supported here, but only a smaller subset of them is supported on edge. So it depends on on what you need. And also static rendering is not supported on edge, whereas it is on the node environment. Once again, it depends on exactly what you need. So let's understand what edge and serverless functions are and when to use them. An edge function is a piece of code that runs on the server at the edge of the network, closer to the user. It is smart and a quick responder. It does the job near you, making things faster. And especially for applications that need immediate actions like handling website requests or managing data from nearby devices. There's a lot of stuff happening right here. And once again, you can compare the edge functions with serverless functions, similarly to how we compared the runtimes together. And a lot of you that work with AWS may compare this with Lambda functions as well, as they're also serverless. It's a completely valid consideration to make and a comparison to make as well. I don't want to go too deep into this. You will have the slides. We're going to mostly likely provide the script as well and a lot of different information on this. So it's definitely something that you can read more into the slides right here. I know we're getting close to three hours already, and I don't want to take the full three hours and maybe more than that, if we dove too deep into all of this. I hope you're okay with me doing that. But once again, both have their own benefits and advantages and disadvantages. You have to think about what exactly do you need, right? Moving on, we have to understand how can we change the runtime in Next.js. Let me see if I can do that here. We already went through it, in a quick example. It's just a matter of fact of switching that export const runtime, which brings me back to my example that we have previously seen, which is running right here. If I can pull it up, there we go, which is why would we decide to use which one and how can we notice the differences? If I can quickly pull up a postman response or request that I've done, we can see it right here. There we go. We can see that if we do a hello from Node runtime, it took about 2.76 seconds to give us back the data. If we check out the same example calling the same function we have in our example from the Edge runtime, it's going to take, place your bets right now if you want to, but it's going to take about 1.8 seconds, which is a second less, which is a huge difference that we have right here. What else could we cover right here? Let me see. In this case, Edge is preferred, of course, if it works with all of the other parameters that you want your app to have because it's located on a server that's near to me. That's it. On the other hand, Node runtime that we have seen right here, that takes 2.7 seconds is located in a server used by Vercel at deployment, which could be far away from when compared to the other Edge runtime. That's good. Let's quickly open this up right here. Go back to the presentation. The question is, should we use Edge over Node? It makes it obvious. It's going to take one second less. The answer to that question is not at all. Edge has also its own limitations. These include quick, but not infinite. Edge functions need to respond within 25 seconds initially. They're like speedy helpers, but they can't take forever to do their job. In this case, it takes more than 25 seconds. They're going to expire. You have to watch the size because these functions can handle up to 4 megabytes of data, including all the code. It's like having a small backpack, fit what you need, but not everything. Also, mind the distance. If your data source is far from the Edge function works, it might take a bit longer. It's like asking a friend to do something, but they need to travel a bit first. You can tweak the settings to reduce that travel time. Finally, not all tricks are allowed. Some cool tricks like the JavaScript knows, Edge functions might not. It's like having a special toolbox where not all the tools are there. You can check a list of tools that we discussed before. Some limited API functionality. Let's see. That's clear. Again, when should we consider using Edge over Node runtime? That's a question. Once again, we get back to it depends. It depends on what you need. Here's some questions that I ask myself. What's the nature of your feature? Is it a latency sensitive task? If it's not, simply use a Node.js runtime or serverless functions. It works just as well. If it is a latency sensitive task, is it crossing Edge limitations? Do you need to use some APIs which Edge functions don't have access to? If it is, then go back to using Node.js runtime. If it's not, use Edge runtime or Edge functions. Always remember to check specific use case depending on the constraints and depending on what you want to do to make an informed development decision. Here are a few use case examples of Edge runtimes. I want to ask you, maybe. Let me do that first. Do you have an example of where you might want to use Edge runtimes instead of Node? One example are... Yeah. Instant messaging is a great example. I think the same idea is notifications or live messages. That's actually great. Great work.

Great. Great work. Also authentication and authorization. Handling user auth at the Edge can reduce latency for login processes, enhancing the login experience, which we have to do so often. And also geolocation services that we discussed right here. Implementing location-based services such as geolocation tracking or local recommendations by processing location data at the Edge. And there are many similar use cases. Edge functions are also often used in CDNs to deliver web content like images, video, scripts from servers closer to users. CDN, right? Now that you talk about it, it's quite similar to what we have been explaining or describing Edge functions as. This reduces load times for websites, improving the overall user experience. That's something we learned already.

So that's about it. Edge versus Node runtimes, Edge versus serverless functions, when to use them, how to use them, and everything else. And Halil, I can see one question more is, and that is, how can we enable Edge? And your question is entirely right. We just add runtime Edge, where you're calling that request. And that's it. That immediately makes your call based off of the Edge endpoints right here. Export const runtime is Edge, and it just works right off the bat.

One more thing I want to talk about is that now that we are at the final part of this workshop, I hope you gained a lot of knowledge and kind of got at least a little part of what you were looking for. Using all of these features we learned is amazing. But if people don't see it, then there's no need to use those features after all. It's kind of typical that thing that development is sometimes the easy part, but the marketing is the hard one, right? We build these websites for people to use. So it's our responsibility to find a solution in a way that's going to give us a lot of traffic on our site and make it noticeable on a sea of different websites online, right? And there are many ways to do that via the non-developer way, meaning that your company or your teams can either create ads, funny memes, or a lot of social content and stay active on all of those. But this is a non-organic traffic, meaning that you have to pay to get some traffic. On the other hand, organic traffic is what we as developers can do inside of our code where crawlers will be able to index them properly on search engines. And I think you can see where I'm going with this. The last topic of today's workshop is SEO, right? How can we impress different picky cats right here to visit your website? Well imagine your cat is the internet, and it only pays attention to the shiniest, most interesting toys, which are websites. So if SEO is your way of making your website the coolest, sparkliest cat toy in the room, we can use the right tricks, which are keywords, arranging things neatly on the site structure and making sure your cat enjoys playing with it, which is the user experience. And the better you do this, the more your cat or the search engine will show your awesome toys to other users, resulting in more people to use it. Of course this is a whole topic and a workshop on its own, and not necessarily fully related with what we're talking about, which is Next.js, but there are many ways on how we can work with those in Next.js. So I just want to quickly go over this. You can improve SEO by improving keywords, right? Making sure they're labeled properly and crawled by the websites. You can improve the content quality of your websites by creating high quality lead magnets for users. You can write better meta tags on your websites as well, or improve your website structure as well. That helps with SEO too. A well-organized structure helps quite a lot. You can improve your site speed, which is another thing, to have kind of express lanes to visit your website, because users don't want to wait anymore. It has been proven that Google ranks websites with higher speed times or load times, more highly on the list than other ones. Backlinks as well. We need to put a lot of backlinks and we need to clear our URLs, but there's a lot of things that we have learned so far. But how can we actually add that metadata to our application? That's something we want to discuss further in Next.js specifically, right? I want to skip this part. You can read it later on. Most of you know what SEO is and what you can do, but how can we do this in Next.js? There's two ways. We can do it using the config, or let's dive into the config part a bit. We can do that by creating both static or dynamic metadata objects using the Next.js API of metadata. We can do it statically, like this, where we can just write export const metadata js mastery, and then write a description and that's going to get added to your site's metadata. It's static. Any content within the title here will be added to HTML title tag and description will be turned into the meta tag. So the above output will just return this. Title in the meta with the description. Pretty cool and easy way to add metadata. We also have dynamic metadata. If there are dynamically generated websites or dynamic routes that we want to search engines to index, which is a best practice, we can use the generate metadata function from Next.js to produce metadata specifically tailored to these pages. For example, to show you, I have implemented this strategy on the JavaScript master website for resources, where we host different resources people can learn from. You can see different titles and descriptions. If you click on one of these resources, you'll see a change in the title and description as well. Let me quickly open it up and just pull it right here. I think I have done it. There we go. If I go into one of these, we can see that right now the URL is just resources, but if I navigate over to this one, we can see a resource and then a specific ID here. You can also see the title of the website changes to the ultimate React native part. We also have different ones for Next.js and so on. The title, description, and everything else changes. Nothing new, right? We were able to do things like these before as well, but now Next.js makes it so easy to do that. This is what dynamic metadata is. Achieving this is super easy. You just call the generate metadata, you pass the params, and then you render the title by getting the resource title from the database or whatever else you're getting it. Then you can also modify all the other tags like this, SEO description, OG images, titles, Twitter titles, Twitter descriptions, and more to ensure that all of your routes look good. Finally, there's the file-based metadata where we can put things like robot files, robot.txts, favicons, sitemaps, open graphs, and more. Do note that file-based metadata has higher priority and will override any config-based metadata. I have prepared one final demo example for SEO for you, but I think we can skip it. I hope that's going to prompt you to actually open up not only this SEO metadata file-based example, but also all the other ones once you're checking for this one. We covered a lot of ground right here. I'm a bit out of breath, to be completely honest, but I do hope that you have found this valuable. I hope you learned a thing or two about Next.js, about React, React server components, and that's it. Do you have any thoughts so far? Do you have any additional questions? I'm hoping that we can continue this discussion on Discord. I didn't open it up myself. I haven't been looking at it so far on my screen. I guess I can quickly get it running right here. We can see what's happening. If I open up Discord, and if I pull it up right here, we should be able to see it together. There we go. It should be here. If I open this up, it's under the Git Nation Discord. They have created it for us. It's a form right here posted 52 minutes ago, and we can see Vanessa greeted us. We can keep all of the questions related to this workshop right within this Discord forum right here. It's created and hosted by Git Nation, but I think they're going to allow us to just keep the communication going, share all of the useful links, and everything else that we might find and share with others. You guys had some great questions today, but I'm sure that you will have many more specific questions, maybe more tougher questions. Maybe think about this once this settles down a bit.

Let me just go through comments quickly. Yeah. So Jada really conveniently shared the GitHub repo as well. So in this GitHub repo, we are able to go through all of the examples very nicely. We're going to link it to Discord as well, so you can reopen them, test them out. The examples are incredibly minimal, which should allow you to just really nicely take what you need and then implement them on your own projects.

On this topic, I want to thank Sujata as well for being here, answering a couple of questions. I wanted to have her. She's a part of a team, and she was able to answer some of your questions in the chat as well as jump into the call. So yeah. Huge thanks to Sujata as well. Yes, Simon, we will look into the way of providing you with the slides too. They might be a couple of gigabytes even when compressed because there's a lot of slides, but we might share a Figma link to those slides as well on Discord. Every piece of information that I can get for you guys, I'll prepare it, and I will drop it in this link on Discord. Just so we don't lose it, I want to copy it, and I'm going to drop it right here. Let me see. There we go. I'm going to paste it in the chat right here. So one more time, if anybody cannot find it, you have it. Let me just go to your comments. I can see a lot of great words, people saying that they like the workshop. I'm really happy to hear that. I want to thank you, not me for doing this, but thank you for being here and actually dedicating three hours of your Friday today to be with me and to learn about Next.js. I hope to see some great websites and phenomenal websites that you're going to create with Next.js. No websites, comprehensive dedicated web applications for that matter. Thank you so much for the kind words.

On the topic of a bit of who we are and what we do, if you don't know, I can share maybe a bit more on that. I think we have it here. We have started doing Next.js a long time ago, ever since 13 or 12, we're in alpha, new features are coming along. I've actually created a course on the topic as well. It's under jsmastery.pro, right here. We try to make it only in the best Next.js course out there. As with the workshop, we dive deep into some parts and we do it in an example as well. The premise of the course, and this is not just me selling it, this is me extending the workshop as well and talking about the idea and process of creation of the course. The idea was to completely modify your mindset for writing Next.js code because Next.js 12 and before is completely different from Next.js 13 and 14. Why? Because it's not just as writing good old React code. It brought many differences to the way that we write React with these hydration errors, the use server, server actions, stale data, data fetching on different parts, edge versus no run times, dynamic imports. You cannot just jump into it like you're using React. That's what we did, actually. I built our entire course platform, our landing pages and everything, and we ended up turning it into a client-side mess. But now, thankfully, we have learned how to do it and if you dedicate this approach, you can have phenomenal performance due to all of the benefits that it provides. If you're interested, in the course, we dive into deep dive into all of these lectures with great slides, like similar to ones you've seen. We dive into the build and deploy of a stack overflow application, which we're going to build from scratch to be able to internalize those processes, and then active lessons that allow you to really ensure that you not only follow along, but actually build in practice based off of the tasks that we give you, for example, creating the filtering, or the searching capabilities and so much more, all while building this stack overflow application. We wanted to do something that is quite interesting, where you have CRUD operations, you have following, liking, commenting, nested comments, chat GPT, AI-generated answers, you name it, it's there. Quite a lot of stuff is happening. But on the other hand, for the longest time, we have been just doing YouTube. For about five years or even more, I've been producing just free educational content on YouTube. Let me just exit out of this, not to have any audio happening. We do it for a long time. Every two weeks, we release one new video, and most of the recent ones have been exactly about Next 13 and 14. For example, building E-commerce applications, using server actions, this is a great video that we have created specifically about server actions, portfolio, social apps, you name it, it's there. That's what we have been doing for the past five years. We dove into Next.js as if server actions were still an alpha, and we tried to go through the trial and error process of figuring it out on our own. Our Next.js full course is one of the fastest growing Next.js courses on YouTube right now, and feel free to kind of consume it, but more than that, I want to invite you to use that Discord server that I showed you, the forum, to ask any questions, and myself and Sujata will directly answer you if we can help in any other way. Recently, we have also started a bootcamp program called the JSM Masterclass Experience, where we really try to help people go from junior to mid or senior positions. I'm not sure where you are right now in your developer journey. Would you mind letting me know? You can do, let's say, unemployed, junior, mid, senior. You can write it down in the comments, just to figure out who was listening to this workshop today. Interesting. I can see junior, but then I can see a couple of seniors as well, head of engineering as well, Philippe, that's great. Okay, mostly senior and mid, which is interesting to hear. From your perspective, did you know about most of these Next.js things, and kind of how did you find them? Let me ask you, let me ask you this. How do you think the landscape of web development and React development specifically will change now that Next.js is making all of these introductions of these features and incorporating them on top of React? If anybody would like to kind of start the conversation, and maybe even on your mic, especially seniors, how do you think the landscape of web development will change? Are you welcoming these changes with open arms, or do you think kind of Next.js still has a long way to go? Okay, I can see some people kind of suggesting that to push to newer features, especially when upgrading to React 18. It will be massive. I only have the fear of being Vercel bound. That's a really good point that a lot of other people make as well. Although, you know, that's a good one, that's a good one actually. But yeah, Next.js does allow you to exit out of Vercel, but they make it so convenient to stay with Vercel that you necessarily don't want to move, right? But I do get your concern. Thank you so much, guys, for being here. I see a couple people have to go. We have hit our time limit as well. You have been a phenomenal, but quiet audience. I hope you were able to learn a lot, and I hope to see you maybe, I don't know, in person next time on Git Nation's conference, or one of the conferences, or I see you on the internet. You can also add me on LinkedIn. I'm happy to chat and kind of exchange some thoughts as well. But first of all, I'll see you on Discord in the forum. We can keep the conversation going on there. Thank you so much and have a wonderful day.