Chapter 4: Organizing the Code Base and Fetching Data in Next.js

Next.js initially became popular thanks to its ability to make it easy to render React pages on the server instead of the client only. However, to render specific components, we often need some data coming from external sources such as APIs and databases.

In this chapter, we will first see how to organize our folder structure, as this will be the determinant for keeping the Next.js dataflow neat when managing the application state (as we will see in Chapter 5, Managing Local and Global States in Next.js), and then we will see how to integrate external REST and GraphQL APIs, both on client and server-side.

As our application grows, its complexity will inevitably increase, and we need to be prepared for this since the bootstrapping phase of the project. As soon as we implement new features, we will need to add new components, utilities, styles, and pages. For that reason, we will take a closer look at organizing our...

Technical requirements

To run the code examples in this chapter, you need to have both Node.js and npm installed on your local machine. If you prefer, you can use an online IDE such as https://repl.it or https://codesandbox.io, as they both support Next.js and you don't need to install any dependency on your computer.

You can find the code base for this chapter on GitHub: https://github.com/PacktPublishing/Real-World-Next.js.

Organizing the folder structure

Organizing your new project's folder structure neatly and clearly is incredibly important in terms of keeping your code base scalable and maintainable.

As we've already seen, Next.js forces you to place some files and folders in particular locations of your code base (think of _app.js and _documents.js files, the pages/ and public/ directories, and so on), but it also provides a way to customize their placement inside your project repository.

We've already seen that, but let's do a quick recap on a default Next.js folder structure:

next-js-app
  - node_modules/
  - package.json
  - pages/
  - public/
  - styles/

Reading from top to bottom, when we create a new Next.js app using create-next-app, we get the following folders:

• node_modules/: The default folder for Node.js project dependencies
• pages/: The directory where we place our pages and build the routing...

Data fetching

As seen in the previous chapters, Next.js allows us to fetch data on both the client and server sides. Server-side data fetching could happen in two different moments: at build time (using getStaticProps for static pages), and at runtime (using getServerSideProps for server-side rendered pages).

Data can come from several resources: databases, search engines, external APIs, filesystems, and many other sources. Even if it's technically possible for Next.js to access a database and query for specific data, I'd personally discourage that approach as Next.js should only care about the frontend of our application.

Let's take an example: we're building a blog, and we want to display an author page showing their name, job title, and biography. In that example, the data is stored in a MySQL database, and we could easily access it using any MySQL client for Node.js.

Even though accessing that data from Next.js can be relatively easy, it would make...

Summary

In this chapter, we've taken a look at two crucial topics when talking about Next.js: the project structure organization and the different ways of fetching data. Even if these two topics seem unrelated, being able to logically separate components and utilities, and fetching data in different ways, are essential skills that will allow you to better understand the next chapter, Chapter 5, Managing Local and Global States in Next.js. As we've seen in this chapter, the complexity of any application can only grow over time as we add more features, bug fixes, and suchlike. Having a well-organized folder structure and a clear data flow can help us keep track of our application's state.

We've also taken a look at how to fetch data using GraphQL. This is an exciting topic as, in the next chapter, we will see how to use Apollo Client as a state manager other than a GraphQL client.