Introduction to the

Next. Js is one of the most important and widely used React frameworks. Today, it has become a comprehensive framework for building amazing web applications.

There are many advantages to listing when working with next.js. Performance, SEO, rich developer experience, TypeScript support, smart bundling, and route prefetch are just a few examples.

For all the amazing features that next.js offers, one feature in particular is very powerful and amazing: the ability to use different pre-rendering techniques.

We can use server-side rendering (SSR) and static Web site generation (SSG) in the same next.js application. We can also make our server-side render application, which still has some generated pages.

In this article, we’ll take a closer look at how these two pre-rendering techniques work and how to use them. We’ll also learn more about how these two technologies are used.

SSR (server-side rendering

Modern JavaScript frameworks have made life easier for our developers. There are many different rendering techniques we can use to create powerful, rich web applications.

You’ve probably heard of single-page apps. A single-page application is an application rendered on the client side, even though the data may be fetched from the server.

Server-side rendering (SSR) is the complete opposite. SSR describes the process of pre-rendering pages on the server and then generating them on each user request.

When the pre-rendered page arrives at the browser, JavaScript code is run to make the page interactive. This whole process makes loading faster. It also makes server-side rendering easier and desirable for applications that rely on SEARCH engine optimization.

Next. Js does this right out of the box. By default, it will try to detect which pre-rendering technique your application is using and retrieve your data.

A few years ago, before JavaScript became so mature and powerful, developers used to return HTML files based on HTTP calls. It is a very common technique to process the response on the server side using a server-side language (usually PHP) and return a static HTML file.

SSG (static web site generation

Statically generated websites are not new to developers. We’ve been building them since the beginning of the web. Building a rich web experience can be difficult, but with Next. Js, we can do it easily.

Next. Js shows us a better way to build statically generated websites with more dynamic performance.

SSG describes the process of building a website, rendering at build time. The output is an HTML file, assets such as JavaScript and CSS, and some other static files.

When SSG is used with next.js, the page is prerendered at compile time. This means that users don’t have to wait for a page to load in the browser; The page will be rendered simply.

For retrieving data, next.js provides three different functions.

  • getStaticProps. At build time, the page will be pre-rendered.
  • getServerSideProps: pages will be pre-rendered at run time.
  • getStaticPaths. This function generates a list of pages that will be pre-rendered at build time

The biggest disadvantage of using SSG is that the build time can become very long. This isn’t a problem when you only have a few statically generated pages, but as your application grows, build time increases.

In the worst case, you have hundreds of statically generated pages. Build times can be long, and if you have dynamic content on these pages, you might have too many build results.

Which one should I use?

Next. Js makes it very easy to pick the right pre-rendering technique for each page.

Remember, we know that Next. Js does static site generation by default. It’s just out of the box. However, it will attempt to detect the pre-render method you use on each page.

In some cases, choosing the right function to get your data definitely makes a difference. This should be taken into account because it can have a huge impact on the user experience.

Imagine that we are creating a simple blog site. Content will be completely statically generated, right? We will only have a few pages and the content will be fetched from our servers, so in this case it makes complete sense to use SSG.

We can assume that every blog has at least two basic pages.

  • posts. This page is responsible for getting and displaying all blog posts
  • post. This page is responsible for getting and displaying a specific blog post

On our Posts page, we can use SSG to get all of our blog posts, using the getStaticProps function.

export default function Posts({ posts }) {
  return (
    <div>
      <h1>My latest posts</h1>
      {posts.map((post) => (
        <h2>{post.title}</h2>
      ))}
    </div>
  );
}

export async function getStaticProps() {
  return {
    props: { 
      posts: await fetchPosts(),
    }
  };
}

Copy the code

The fetchPosts function will be run at build time. It gets our external data and prerenders the content for our pages.

Now, imagine that we want to add a small feature to our simple blog site.

Imagine that we are a very famous person and our followers want to buy items from our store. We wanted to turn our simple blogging site into an e-commerce application and start selling items like shirts, mugs and stickers.

All components contained in an e-commerce application can use the same pre-rendering techniques. We can use the getStaticProps function at build time to get our data.

Now, what can we use for our check-out? Every e-commerce application must have a checkout session where the user will end their purchase. In this case, the data can be retrieved from our database at build time, but it may be different for each user.

We can use client fetching on top of SSG to render our pages. We can create our simple components without using any functions to get data at build time. In our components, we can use a data capture library, such as SWR, to get our data on the client side.

import useSWR from "swr"; export default function CheckoutSession() { const { data, error } = useSWR("/api/checkout", fetcher) if (error) return <div>Something went wrong... </div> if (! data) return <div>Loading... </div> return <div>Cart: {data.items.length}</div> }Copy the code

Using server-side rendering with getServerSideProps, you can get the job done in most cases. The problem is that you may lose some of the functionality and advantages that SSG brings to your Next. Js application. The page will be pre-rendered with the returned data on each request. The other disadvantage is, You can’t use one [fetch()]([https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch](https://developer.mozilla.org/en-US/d Ocs /Web/API/Fetch_API/Using_Fetch)) method to call the API in getServerSideProps.

In fact, pages are pre-rendered at build time, which improves performance and makes pages feel faster.

HTML can also be retrieved from the CDN server, which can also improve performance.

Another nice feature of SSG is that no requests are made to the database. Pages are pre-rendered at build time, so even if your database fails, you will still be able to render your pages.

conclusion

Next. Js has become one of the most important React frameworks in the web community. It brings a lot of functionality to developers to help them build more complex and rich websites.

Using frameworks like next.js, we can use different pre-rendering techniques on our applications. We can use static sites to generate something simpler and less dynamic. We can use server-side rendering for dynamic content and more complex pages. With these tools, building rich web applications becomes easier and more fun.

SSG & SSR in next.js first appeared on the LogRocket blog.