The Next.JS framework gives flexibility in choosing when to fetch data from an API, and it can get confusing which you should use. To be clear, the following is my opinion, and the best option depends on your use case.

\
For the following examples, I’ll be fetching a post from an API.

\
# getServerSideProps

```javascript
export async function getServerSideProps(context) {
  const res = await fetch(API_URL)
  const post = await res.json();
  // handle error code(s)
  // return props (post data in this case)
  return {
    props: {
      post: post,
    }
  };
};
```

First up is `getServerSideProps`. Note that the **server** will fetch from the API then render the page as HTML before sending it to the client on *every request*. The major downside of this method, and why I think you should use one of the following alternatives, is that the page won’t be sent to the user until the request is finished. This means that your time-to-first-byte(TTFB) will be longer than other alternatives, and the user will stare at a white screen until the API request is done and Next.js sends the page. When the page is sent, it will be fully hydrated with the fetched data. Because of the long TTFB, `getServerSideProps` is not great for SEO and UX. If it’s important for the user to see the most up-to-date data on every request, then I would consider fetching from the client.

\
# getStaticProps

```javascript
export async function getStaticProps(context) {
  const res = await fetch(API_URL)
  const post = await res.json();
  // If there is an error, the build should fail
  return {
    props: {
      post: post,
    }
  };
};
```

Like `getServerSideProps`, the API request will be sent from the server. However, instead of fetching on every request, it will only be fetched at *build time*. This means that on every request, the server will send the same pre-generated page rather than building a new one, ensuring the fastest TTFB possible. This is a great option if the content from the API doesn’t change often, the user doesn’t need to see the most up-to-date data, and/or you are okay with rebuilding every time you need to update the page’s content (Vercel makes this easy).

\
## Incremental Static Generation

However, if you’re like me and don’t want to have to rebuild the website every time the data changes, such as creating a new post, but still want the benefits of a pre-generated page? Then incremental static generation(iSG) is the solution for you! iSG still uses `getStaticProps` but has an additional `revalidate` attribute. If you want a good walkthrough on what iSG does and how it works, then I suggest reading [this great article](https://arunoda.me/blog/what-is-nextjs-issg) from a previous maintainer of Next.JS. In short, iSG works similar to `stale-while-revalidate` in that the first request will receive the pre-generated page, and the server will begin to rebuild (and thus re-fetch from the API) the updated page if the `revalidate` time has passed since the last rebuild. So now you can have dynamic sites while still sending pre-generated pages and not needing to rebuild the entire site. The drawback is that it will at the very least require 2-page requests for a user to see the updated page. For all of my public-facing pages in my blog engine, this is the option I went with, moving away from `getServerSideProps`.

\
```javascript
export async function getStaticProps(context) {
  let res = await fetch(
    `${process.env.NEXT_PUBLIC_API_URL}/api/v1/posts/${context.params.id}`
  );
  const post = await res.json();

  return {
    revalidate: 3, // time should be adjusted according to the use case
    props: {
      post: post,
    },
  };
}
```

If you have a page in a dynamic path, you also have to add `getStaticPaths` below to tell Next.JS which paths to build initially. In my case for a post page, I’ve added the following to tell Next.JS to build the first page of posts from the pagination request:

\
```javascript
export async function getStaticPaths() {
    let linkPaths = [];
    const res = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/api/v1/posts/get?maxID=-1`);
    const posts = await res.json();

    posts.data.map((post) => {
        linkPaths = [
            ...linkPaths, 
            { 
                params: { 
                    year: post.slug.substring(0,4),
                    month: post.slug.substring(5,7),
                    slug: post.slug.substring(8)
                } 
            }
        ];
    });

    return {
        paths: linkPaths,
        fallback: true // build new page instead of sending 404
    };
}
```

Above I also use the `fallback` key, which tells Next.JS in the event that a user requests a page that hasn’t been built yet, to send a fallback page while the data is fetched instead of a 404 page. For more details, look at the [documentation](https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required).

\
# Client-Side Fetching

The last option of note is client-side fetching, which is best used for cases where the user seeing the most up-to-date information on every request is very important and a low TTFB is still desired. For example, I use this for the editor/admin dashboard in my blog engine - it’s important for the dashboard to accurately show which posts are public, etc. You still get a low TTFB as Next.JS will build a static “template” page without any data, for example, the navbar and general layout of the page. If you do go with this route, I would take a look at [Vercel’s SWR library](https://swr.vercel.app/) or react-query which provides some useful functions for fetching data, such as polling and revalidation on refocusing. Also for UX, I suggest showing a skeleton component while the data is being fetched.

![Example skeleton components in the old blog engine index page](https://blogapi.aqchen.com/assets/images/2020-10-13_02-09-35_e2715ee0f9078ccbb04b5c28e257199b.png)

# TLDR and Final Thoughts

If the data that is displayed to the user changes frequently, and it's important that the user see the most up-to-date data, then you should use `getServerSideProps` (fetches the API data on each request) or send the request from the client-side (

preferred). Fetching from the client vs server is a smaller distinction and the best option may vary depending on the use case. Do consider that if you use `getServerSideProps` to fetch the API but your API server goes down, then the page will no longer be able to be served since the page will fail to build.

\
However, for server pre-generated HTML pages for the lowest TTFB, use incremental static generation. But if the data does not change frequently or it's not important for the user to see the most up-to-date version, and you’re okay with rebuilding the entire site to update content, use `getStaticProps` only.

Alan Chen

Projects

About

GitHub

Contact

Projects

About

GitHub

Contact

Fetching data from an API with Next.JS

getServerSideProps vs. getStaticProps vs. client fetching

September 8th, 2020 (updated October 23rd, 2020)