# Astro Crash Course #11 - Server Side Rendering ## Метаданные - **Канал:** Net Ninja - **YouTube:** https://www.youtube.com/watch?v=HDo9BNE0pH4 - **Дата:** 14.04.2026 - **Длительность:** 6:11 - **Просмотры:** 1,575 - **Источник:** https://ekstraktznaniy.ru/video/49646 ## Описание In this Astro tutorial series, you'll learn how to use the Astro web framework to make a content-driven website. You'll also learn how to add React components to the site, and deploy the finished application to Netlify. 🍿👇 Get early access to the whole course on NetNinja.dev https://netninja.dev/p/astro-crash-course 🔥👇 Get access to ALL Masterclasses & premium courses with a Net Ninja Pro membership: https://netninja.dev/p/net-ninja-pro/#prosignup 🔗👇 Course files on GitHub: https://github.com/iamshaunjp/Astro-Crash-Course 🔗👇 Astro Docs: https://docs.astro.build/en/getting-started/ ## Транскрипт ### Segment 1 (00:00 - 05:00) [] Okay, then my friends. So far, when we've been making this website, we've been doing so in such a way that all the pages are built by Astro at build time, right? And we end up with a static site with a bunch of pre-rendered pages that we can then deploy. Even with all the book details pages, we've used the get static path function to build out a page for each and every book review markdown file that we have, and all of these pages are pre-rendered, pre-built, and after the site gets deployed, the server doesn't need to do anything to render any new pages or content, right? It's all done beforehand. However, sometimes building and rendering all the pages at build time doesn't suit what we need from a website, and sometimes we need pages rendering on the server on demand. For example, it might be that your site uses maybe an external API to fetch content, and that content could change constantly. For example, it could be a list of products which get updated frequently throughout the day. And for something like that, having a statically built page wouldn't really be appropriate because it would likely show out of date product content as the product data changes. Another example would be a user dashboard page. We couldn't statically build that page because it would change for each user, and also probably update quite frequently, too. And it would require them to authenticate. So, ideally, when you've got a lot of data changes, you need to build and render those pages on demand on the server when the request comes from the client. And we can do that with Astro. We can tell it that for certain pages, we want it to be rendered on the server on demand and not at build time. So, to demo this, I've already added a new product folder, and inside that an index page component. So, the path to reach this page would just be forward slash products, right? Inside this component, I've already done some very basic setup by making the front matter section with the layout import, and also this product interface ready for the data we'll be fetching. I've also added a basic template that uses the layout. The next thing I want to do then is tell Astro to render this component not at build time, but on demand on the server. And to do that, the first thing we'll need to do is add something called a server adapter to the project. So, like we've already talked about in this series several times, by default, Astro renders everything at build time, and thereafter, the server doesn't need to do any work because everything's already been built into static HTML pages, and the only thing left to do is serve them to the browser. However, when we need the server to do some work like rendering pages on demand, we can opt in to that by adding a server adapter. Now, there's a bunch of different server adapters available, and depending on where you deploy your Astro site to, you'll want to choose an adapter appropriate for that service. Out of the box, Astro maintains four server adapters for Cloudflare, Netlify Netlify, Node, or Vercel. I'm eventually going to be deploying this site to Netlify, so I'm going to select that one right here. Now, when you click on that, it's going to show us some installation instructions, and the easiest way to add the adapter is to use this command right here, which is npx astro add netlify. So, let's copy that command and then head back to the code. Okay, so I'm going to paste that command in right here and then press enter, and when I do that, we'll have to walk through a few questions. The first one is to give permission for Astro to run an install command, so I'm going to hit enter to select yes for that. And then after that, it's going to want to make changes to the Astro config file to register the new server adapter, so we can hit yes for this as well. And once that's done, the Netlify server adapter is ready to be used, and we just need to do one more thing to mark a page component as an on-demand one, so not one that's going to be pre-built. So, let's come back to the products component then, and at the top of the front matter, we should say export and then a constant, and this is going to be called pre-render. And it must be called this exactly. Then we set that equal to false. And this is us telling Astro that we don't want it to render the page at build time, but instead render it on demand on the server when a request comes in for it. And that means that every time a user requests this page, it's going to get a newly rendered up-to-date version of the page and not a pre-built one. So, we've added the adapter, we've added this export to the top of the component, and now we just need to make the page as normal. So then, I've already made this interface right here called product, right? Which only defines a title property, which must be a string. And now I want to fetch the product data from some endpoints. Now, for the sake of this tutorial, we're going to be using a dummy JSON API which returns some dummy JSON data, but in reality, you might be using your own endpoints or database. But anyway, we can fetch data directly from this front matter using the fetch API, and then whenever a request for this page hits the server, the fetch for the data gets run, making sure we get the freshest data available, and then the page gets built and sent ### Segment 2 (05:00 - 06:00) [5:00] back to the browser using that data. So, I'm just going to paste this fetch in, and it's all really simple. We just make the fetch request to this dummy JSON endpoint, and then we parse the JSON, we access the products property on it, which is then going to return an array of products. So then, in the template down here, we can output those products. So, let's do that. I'm going to use some curly braces, and then I'm going to say products. map and invoke it. take each product in the callback function, and I want to return a little bit of template for each one inside parentheses. And the only thing I really want to return is a div tag, where we can just output the product title by using curly braces and then saying product. title inside them. Then we can save this file, just test it out in the browser. All right, so that works. There we go. And if we refresh, we can see, yep, it's still working. Awesome. So, that is how we opt in to server-side rendering. Again, that's important if your data is going to change frequently, and you don't want to keep building your site several times a day, or for dynamic content such as a user if they have to authenticate and we need that user data for a user dashboard or something.