Static is great, you want static

[00:00 - 00:18] In the previous lessons, we have discovered how we can get data from the database and render them directly using a React Server Component. We have also seen how we can create a form in the administration interface that lets us update the data without any client JavaScript thanks to Server Actions.

[00:19 - 00:34] But now we have a problem, the pages that are statically rendered will not be automatically updated when we change data into the database, when we add a new product for instance. Let's give it a try.

[00:35 - 00:53] So we will create "yet another product", make it very expensive, save the change, check the product list and we don't see the product. The problem is that static rendering is kind of contradicting the idea that we want fresh data on the website.

[00:54 - 01:03] Because it's static, it doesn't move. The page is rendered ahead of time during compilation and so it won't update automatically.

[01:04 - 01:14] Okay, if I refresh, I don't get anything. The thing is that many developers at this point will say, "Oh, we just need to switch to dynamic rendering."

[01:15 - 01:29] So request-time rendering so that any new request will get the new product. But the problem is that it's not optimal at all because the thing is that the product list changes when the e-commerce owner adds a new product.

[01:30 - 01:48] Okay But then it doesn't change anymore. So if the e-commerce owner adds only one product per day, maybe, or per hour, all the visitors will trigger new renders during the interval for nothing because the product list didn't change.

[01:49 - 02:01] So instead we are going to try to do something smarter which is having the list to update while keeping it static. It will update only when a new product is added.

[02:02 - 02:20] It seems logical, but it's not that simple and those features have been brought to frameworks like Next.js quite recently. In a sense that React Server Components have been introduced last year but they 've been experimental for a while compared to server-side rendering.

[02:21 - 02:37] Dynamic server-side rendering is quite older. It's been around since almost 10 years now while the revalidation, this way, more like 3 years ago. Because the thing is that for a while, static framework refused the idea to have a running server.

[02:38 - 02:49] Because in order to be able to update the static content, you need the server to recompute the values. And many frameworks just wanted to avoid that and so they prevented themselves to update the static pages.

[02:50 - 03:04] You had to rebuild the whole application. But modern framework like Next.js proposes intermediate features that prevent the need for full rebuild, yet they let you rerender some of the static pages only parts of the website.

[03:05 - 03:14] This is exactly what we are going to do. Maybe it's interesting to do a small parenthesis to explain why we are so interested in static rendering.

[03:15 - 03:25] It's computed ahead of time, okay, thanks to React server components, it doesn 't even need client-side JavaScript anymore, so very great. But that's still a bit conceptual.

[03:26 - 03:33] So let's run an experimentation. We are going to run a load test on my computer simulating a lot of requests and see the response time.

[03:34 - 03:41] So here my server is running in a terminal, okay, I've launched it. It's running on port 3000.

[03:42 - 03:57] The problem is that it's blocking the terminal, so I have to create a new one. And I will use this library "loadtest" and I will have it to query the server, the development server.

[03:58 - 04:14] So I'm running a built version of the application simulating a real deployment, basically not the development version, so it's more realistic. So I'm going to trigger the test on the home page, say, okay, I need to add "npm exec".

[04:15 - 04:34] So the load test is running, it simulating many, many, many requests, computing the latency, and it gives me some results saying that it sent 21,000 requests roughly. It took 10 seconds and the mean latency is less than 30 milliseconds.

[04:35 - 04:54] Okay, it's not a real network request in the sense that I querying my own machine, so you should add the network communication, but it's quite fast. You see that the 99% is 60 millisecond, and the worst request is 100 millisec ond, but it's an anomaly, something that you cannot avoid.

[04:55 - 05:08] 99% of the request took only 60 millisecond to run on my computer. And given that I'm both running the load test and the server, so you will have to try again on your own server, but those are very good stats.

[05:09 - 05:21] Because Amazon computed that 100 millisecond loading time would make them lose 1% in revenue. And we are under 100 millisecond, if we can do any better, so that's really great.

[05:22 - 05:33] Remember this Google statistic: a mobile website can take 15 seconds in average to load, so we are good with the 100 milliseconds. That's very satisfying.

[05:34 - 05:40] But now back to our refreshing problem. The problem is that it's cool, its performant, but it's kind of dead.

[05:41 - 05:52] And I don't want my static rendering to be stale rendering. I don't want my static rendering to display an outdated list of products on the product page.

[05:53 - 06:08] It's not good, it's not acceptable. So we are going to discover two APIs that simply let us figure a new render of the application of the pages or the content that should be updated after an update in the database.