ReactJS

How to Choose Between Data Fetching Options in Next.js

Published May 18, 2022

Updated Feb 13, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

A few days ago, we published another blog post related to Next.js: Understanding Next.js Data Fetching for Beginners.

In that blog post, we show the functions this framework provides us to perform different data fetching options. I hope you already have a basic understanding of Next.js. If not, I highly recommend that you first read the article linked above.

Let's get started.

There are multiple strategies for us to choose from, and it gets confusing at first to apply the correct solution in the correct place. We will take a real-life application, and understand which strategy works best for which scenarios.

The special functions that are used for pre-rendering in Next.js are:

getStaticProps
getStaticPaths
getServerSideProps

We will see in which scenarios you can apply these functions, and learn the best practices for doing so.

We are talking about an Online Store

Let's assume that we want to build an Online Store to display some products, a product page (and details), and an accounts page (order details, personal info, etc). Let's also assume that we don't want to use React because we want to optimize SEO.

Let's start thinking about this.

Landing Page (getStaticProps)

The landing of our OnlineStore is where you can see two things, the list of some products you want to highlight could be:

Featured Products
Popular products
Discounted Products
Upcoming Products

Whatever the case, the main thing is you already know which API you will be using, and probably that API will not change in the short term. In these scenarios, only getStaticProps is enough.

As we see in our previous post:

export async function getStaticProps() {
    const url = 'https://our-api-products.com/';
    const res = await fetch(url, {
        headers: {
        Accept: 'application/json',
        },
    });
    const data = await res.json();

    return {
        props: {
            products: data.products,
        },
    };
}

Now, our landing page will be pre-generated ahead of time and won't change. For further details and a breakdown of the getStaticProps method let's check our previous post getStaticProps.

Landing Page, but dynamic (getStaticProps + revalidate).

What happens if the landing page you are building is frequently changing the products based on user preferences? Then, you don't want to show the same page all the time.

In that case, you need to make sure that the generated pages will be updated at a regular interval.

With that in mind, you have to use the revalidate property. This property is defined in seconds to indicate the refresh interval.

export async function getStaticProps() {
    const url = 'https://our-api-products.com/';
    const res = await fetch(url, {
        headers: {
        Accept: 'application/json',
        },
    });
    const data = await res.json();

    return {
        props: {
            products: data.products,
        },
        revalidate: 20
    };
}

We gave our revalidate property the value of 20. It means we are still pre-generating our landing page, but it will be updated every 10 seconds. As we see in our previous post, this is called Incremental Static Regeneration.

Product detail (getStaticPaths)

Now, if for example, our customers click on one product, we have to show a details page of the product. We're calling a PI, like the product/?id=678.

What is interesting here, is we don't know which id we are looking for. So our server needs to know all of the valid ids ahead of time.

This is where getStaticPaths comes in. It tells the server all the available routes that we need to pre-generate.

export async function getStaticPaths() {
    const idList = getproducts().map(product => product.id)
    const params = idList.map(id => ({params: {productId: id}}))

    return {
        fallback: false,
        paths: params,
    };
}

export async function getStaticProps(context: GetStaticPropsContext) {
    const {params: { productId }} = context
    const productDetails = await getProductDetails(productId);

    return {
        props: { productDetails, }
    };
}

Now, only the pages with a valid id will be pre-generated.

Accounts Details (getServerSideProps)

Now, what if our customer wants to see her last purchases, or change her address or other personal info? After that, we need to validate some things.

Or, we want to make sure that the user has the right permissions to view the page. In these scenarios, we use getServerSideProps.

If you remember, in our previous post we talk about getServerSideProps, this option will not pre-generate any page. Instead, it will run the code inside the method every time the page is requested. Therefore this is more secure, but unfortunately less efficient.

export async function getServerSideProps() {
  const url = 'https://our-api-products.com/';
  const res = await fetch(url, {
    headers: {
      Accept: 'application/json',
    },
  });
  const data = await res.json();

  return {
    props: {
      products: data.products,
    },
  };
}

Conclusion

That's it. First, we saw different data-fetching options. Now, we see how to choose between them, in real-life scenarios probably we are facing every day.

Now you should have a little understanding of how we can use NextJS for improved performance and SEO-Friendly in your application.

So far, we learned:

If we had a page in which the content will be the same and will remain the same for a long time, it's better to use getStaticProps.
If we need a page whose content will be dynamic based on some conditions, it's better to use getStaticProps with a revalidating option.
On the other hand, if we want to build a page and be sure that the id items are all valid, it's more likely to use getStaticPaths.
But, if we need to make a secure but dynamic page, we will definitely need getServerSideProps.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Daian Scuarissi
@asdaian @SDaian

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Danny Thompson, Director of Technology at This Dot Labs, talks with Tanner Linsley, Creator of TanStack, about his latest project, TanStack Start. They discuss the challenges of existing frameworks like Next.js and Remix, the development of TanStack Router, and the future of React Server Components. Tanner also explains how caching strategies and fine-grained invalidation can transform the user experience. Chapters - - Introduction & Tanner’s Background (00:00) - Going Full-Time on TanStack (01:00) - The Birth of TanStack Router (02:21) - Why Build Another Framework? (04:00) - React Server Components: Potential & Limitations (07:05) - Fine-Grained Cache Invalidation & UX (09:02) - Parallel Data Fetching in Routing (13:39) - TanStack Start: Alpha & Future Plans (16:41) - Where to Learn More About TanStack (18:48) Find Tanner Linsley on Social Media Twitter: https://x.com/tannerlinsley Linkedin: https://www.linkedin.com/in/tannerlinsley/ Github: https://github.com/tannerlinsley TanStack: https://tanstack.com/ Sponsored by Wix Studio...

Oct 9, 2024

1 min

TanStack QueryJavaScriptReact

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Understanding Next.js Data Fetching for Beginners

When I started to learn Next.Js, I felt a little bit lost with some abbreviations they use to make the data fetching. All of them look pretty simmilar, but they have different meanings. If you feel the same, you are not alone. Let's discover what CSR, SSR, SSG, and ISR means, and how we can use them. It is quite confusing because I, as an Angular developer, only knew one strategy to fetch the data:HttpClient. But for example, if you are more familiar with React, you probably use a different strategy: useEffect. So, let's get started. Vercel's Next.js framework has four different data fetching options despite being known as a server-side render framework: - CSR - Client-Side Rendering is a common data fetching method using useEffect. It will fetch the data from the API every single page request on the client-side (after the page is rendered, then the function will run). - SSR - Server-Side Rendering will run a special function to fetch data from the API with every page request on the server-side (before the page is loaded, that special function will run first, creating a delay, then after that, it will serve the page). - SSG - Static Site Generation will run a special function to fetch data once when that page builds. - ISR – Incremental Static Regeneration offers a new method. Shortly put, it is a combination of SSG, and SSR, where it served statically, but at a certain time and certain condition, that page will rebuild and fetch the data from the API again. Don't worry if you don't understand any of the concepts. I will explain a little bit further shortly. CSR (Client-Side Rendering) This is a basic example of how you can use Client-Side Rendering. I'm using the well known useEffect method from React. ` You can see how it works on Stackblitz. We can highlight 2 things here: - The useEffect method to make the retrieve of the name every time the page loads. - A loading indicator, this is used to wait for the fetching data, because the data is fetched after the page is rendered. SSR (Server-Side Rendering) Just to keep in mind, when you are using Server-Side rendering, and using the method getServerSideProps(), Next.js will pre-render this page on each request using the data returned by getServerSideProps. ` You can see how it works: Stackblitz We had 3 highlights here: - Method getServerSideProps(), is a function indicating that a page is using Server-Side Rendering. - We had a delay before render, and NO loading indicator. The data is fetched before the page is rendered, so that's why we can see a little delay. - Data is fetched on every request, that's why every time we reload the page, is showing a different dad joke. SSG (Static Site Generator) If we take a look at the code below, we will see that it is pretty similar to the SSR code, but the difference here is the getStaticProps method. This method will only fetch when the app is building. ` The highlights here are: - getStaticProps is a method indicating that the page is using Static Site Generation. - Data will be fetched only when you run yarn build. The API will be hit only when the app is building. - Data will NOT change because there is no further fetch. You can see how it works: Stackblitz ISR (Incremental Static Regeneration) This strategy works pretty simmilar like SSG, but here we need to add a revalidate prop to our main getStaticProps function. ` There are a few keys to highlight here: - When you set the revalidate prop to certain amount of time (in our example we set it to 20), reloading doesn't trigger changes. The page will remain in a cooldown state. - Is the page rebuilt every 20 seconds then? No. When the cooldown state is off, if no one visits the page, it will not rebuild even after the 20s pass. But the first person who enters the page when the cooldown state is off will trigger a rebuild. However, that person will not see those changes. But the changes will be applied to the next full reload. You can see how it works: Stackblitz Conclusion Understand how these abbreviations work, and how we can use it in a Next.js app will help us develop more robust solutions, and use Next.js' full potential. I know these terms can sound overwhelming and difficult to understand, but with a little bit of practicing, we can see in action in a few steps. In future blog posts, we will see the best approach to identify and choose between them....

May 9, 2022

4 mins

NextJSJavaScriptReact

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to Choose Between Data Fetching Options in Next.js

We are talking about an Online Store

Landing Page (getStaticProps)

Landing Page, but dynamic (getStaticProps + revalidate).

Product detail (getStaticPaths)

Accounts Details (getServerSideProps)

Conclusion

Daian Scuarissi

You might also like

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Introduction to Zod for Data Validation

Understanding Next.js Data Fetching for Beginners

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

The Journey To Making A New Framework: TanStack Start with Tanner Linsley

Introduction to Zod for Data Validation

Understanding Next.js Data Fetching for Beginners

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh