You already built great web applications with React, you love this framework so much but you realized it doesn't fit all your needs.. and this makes you sad :crying_cat_face:. Sometimes you want:
* static and server rendering
* route pre-fetching
* automatic routing system
* built-in image optimization
* smooth serverless deployments
* SEO optimization
* And many more...

Well, this is your lucky day :four_leaf_clover:. Next.js adds these missing features.

## :warning: Disclamer
If you never used React before, this article might not be for you. I would rather recommend giving React a try. In fact, Next.js is built on top of this framework and some basics React concepts are needed in order to focus on Next.js.

## Setup
The simple way to [create a new Next.js](https://nextjs.org/docs/getting-started#setup) project is by running `npx create-next-app`, followed by the flag `--typescript`, it will create the new project with Typescript file.

If you want to create the project manually, please [refer to the official documentation](https://nextjs.org/docs/getting-started#manual-setup). For example, maybe you don't want the project to be created with `yarn`. Once the project got installed, here is what you should have (I simplified it a bit):
```

┣ pages/
┃ ┣ api/
┃ ┃ ┗ hello.ts
┃ ┣ index.tsx
┃ ┗ _app.tsx
┣ public/
┃ ┣ favicon.ico
┃ ┗ vercel.svg
┣ styles/
┃ ┣ globals.css
┃ ┗ Home.module.css
┣ next.config.js
┣ package.json
```

Except for the configuration file `next.config.js`, the Next.js project is divided into four parts:
* `pages/api`: see it as an HTTP server for now. This is where the server exposes HTTP routes. In some cases, you don't need an HTTP server and hence, you don't need this part.
* `pages/`: every file in this folder that exports a React component as a default export is a page in the Next.js router. In fact, in our case, `index.tsx` export a default `Home` function component. __the default page must be in `index.tsx`__.
* `public/`: the static served files. this is where we may want to store our images, fonts, etc.
* `styles/`: contains CSS files. `globals.css` for global styles and `[name].module.css` for scoped CSS style. [Learn more about the CSS module feature on the official documentation](https://nextjs.org/docs/basic-features/built-in-css-support#adding-component-level-css).

You can start the application by running the `dev` script command defined inside `package.json` (`npm run dev` or `yarn dev`).

In development mode, the website isn't statically built, instead, it has an HMR (hot module replacement) that gives us a really enjoyable developer experience thanks to webpack. 

## Create a new page
In a React application, you would probably create a new component `About` inside a sub-folder `components`. Then, you need to add this a `Route` (if using react-router-dom) to a `Switch` as a child. And finally, you would have to create a `Link` component in order to link it under other pages.

Let's create a new `About` page and link it to our `Home` (index) page. Create a new `about.tsx` file under `/pages`, and add these basic lines in it:
```typescript
// pages/about.tsx
import React from "react";
import { NextPage } from "next";

const About: NextPage = () => {
  return <p>Hello World from About!</p>;
};

export default About;
```
We can test this page by manually going to http://localhost:3000/about (if you didn't change the webserver port). It's pure magic :tada:!

You can now either remove all the `Home` content or partially update it by adding a `Link` to the freshly created `About` page:
```typescript
// pages/index.tsx
import type { NextPage } from "next";
import Link from "next/link";

const Home: NextPage = () => {
  return (
    <>
      <h1>Hello from Home</h1>
      <Link href="/about">Go to About</Link>
      {/* Or using passHref if you need custom styling on the link */}
      <Link passHref href="/about"><a>Go to about</a></Link>
    </>
  );
};

export default Home;
```
That's it, you've created a page that is linked from `Home`! :clap:

## Image optimization
By default, in React, images don't have any optimizations. Next.js simplifies our life by adding a utility component `Image` exported from `next/image`. This makes sure that:
* Images have cache headers so the browser knows he can keep it in the client cache
* Images size is not too big for the client. For instance, if a container is 900x700 px, the client asks for this dimension even if originally the image was uploaded with a bigger size. You can read this more [on the official Next.js documentation](https://nextjs.org/docs/basic-features/image-optimization#image-sizes)
* Images are served as `.webp`, if you don't know this image format, read more about `.webp` on [MDN](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#webp)

Let's try to include a static image on the `About` page to see how to use an image in Next.js. For the example, I will use this image. If you want to use this image too, you can right-click on it and save it on the Next.js project `/public/images` directory (`/images` doesn't exist yet, you can create it)
![test](https://iziodev-blog-images.s3.eu-west-3.amazonaws.com/how-to-understand-nextjs-when-coming-from-react/Untitled-1.jpg)
Note: Cat :cat: images are not allowed for this example. Feel free to move on to the next paragraph.

All static assets (fonts, images, etc) can be referenced by the code starting from the base URL `/${asset_path}`. In order to reference our image, let's import the image in the file.
```ts
import dogImage from "../public/images/dog.jpg";
```
And just use the `<Image/>` component that Next gives us.
```ts
<Image src={dogImage} alt="Super cute dog!" />
```
<br>
<details>
  <summary>See the whole About page code</summary>
  
```ts
import React from "react";
import { NextPage } from "next";
import Image from "next/image";

import dogImage from "../public/images/dog.jpg";

const About: NextPage = () => {
  return (
    <>
      <p>Hello World from About!</p>
      <Image src={dogImage} alt="Super cute dog!" />
    </>
  );
};

export default About;
```
</details>

By default, the Image fits the parent size restriction, here, there is no restriction. Hence, Next.js will use the whole width (1080px in my case). Try to add a `<div>` around the `<Image/>` tag and restrict the `width` to `600px`. It will use a different image source. This is the size optimization we were talking about.

## Adding dynamic data
Our application looks great but it lacks some dynamic data. Next.Js have three kinds of data-fetching, and they can be confusing at first.
The data fetching logic is coupled to a component, passing the result of the fetching to the component as a prop.

The first one is classic, `getServerSideProps` is making a dynamic request each time the coupled component is mounted, this is the only method that makes requests **not at build time** but instead at runtime. Here is an example that is strongly typed.
```ts
import { GetServerSideProps, InferGetServerSidePropsType } from "next";

export default function MyComponent({}: InferGetServerSidePropsType<
  typeof getServerSideProps
>) {
  return <div>Hello world</div>;
}

export const getServerSideProps: GetServerSideProps = (context) {
  const res = await fetch(`https://...`)
  const data = await res.json()

  return {
    props: {},
  }
}
```
Have you noticed that the function is taking an argument `context`? It would be populated by another data fetching method (if implemented) `getStaticPaths`. This new fetching method is useful when you want multiple pages of a same type. For instance, I use this method on this website for displaying all different article pages. In my case this logic is inside a `[slug].tsx` file inside `pages/blog`
```typescript
export const getStaticPaths: GetStaticPaths = async () => {
  const slugsResponse = await apiClient.get<string[]>("/post/slugs", {
    params: { status: "published" },
  });

  const paths: GetStaticPathsResult["paths"] = slugsResponse.data.map(
    (slug) => ({
      params: { slug },
    })
  );

  return {
    paths,
    fallback: false,
  };
};
```
It's the logic that is defined all the paths under an article. So that the coupled component knows about which slug we are talking about (taking it as a prop).

The last method is `getStaticProps` and it is useful to retrieve data at build time (for static generation), for instance, I use this method for getting data about an article, given its slug that we fetched before, within the `getStaticPaths`, like its title, description, and content. Here is a sample code is taken from my website
```typescript
export const getStaticProps: GetStaticProps<{ article: PostType }> = async (
  context
) => {
  const { params } = context;

  const articleResponse = await apiClient.get<PostType>("/post", {
    params: { slug: params?.slug },
  });
  const article = articleResponse.data;

  return {
    props: {
      article,
    },
  };
};
```
You can go deeper into each of these fetching strategies by looking at the [Next.js documentation](https://nextjs.org/docs/basic-features/data-fetching)

## Introducing the HTTP server
:pencil: Update: Starting from NexT.js version 13, they have introduced middlewares, functions that run before any other requests, this could be useful to implement a global authentication or logging for example.

Let's create a `contact.ts` file inside `pages/api`. Remember that `api` sub-folder contains logic that will be under a listening HTTP server (it's a backend basically), and add this content
```typescript
import type { NextApiRequest, NextApiResponse } from "next";

// Optional, it's just to type response object
type Data = {
  success?: boolean;
  error?: string;
};

export default async (req: NextApiRequest, res: NextApiResponse<Data>) => {
  const customerEmail = req.body.email;
  const customerName = req.body.name;
  const messageContent = req.body.content;

  if (!customerEmail) {
    return res.status(500).json({ error: "Missing email." });
  }

  console.log(req.body);
  return res.status(200).json({ success: true });
};
```
The HTTP server is running on the same port of the website, meaning we can call our endpoint programmatically with this line of code for example
```typescript
const value = {
  email: "test@test.com",
  name: "Test Name",
  content: "Test Content",
};

await axios.post("/api/contact", values);
```
Note that the route we're calling is `/api/contact`, and that is because of the filename `contact.ts`. You can nest folders inside API as you would do with pages of the front-end application.
You can read more about built-in API on [the documentation](https://nextjs.org/docs/api-routes/introduction)

## Environment variables
I'm taking a bit more of your time because this was confusing to me at first. Environment variables are read by default in a Next.js application.
They also have a logic where you can have multiple `.env` files that get loaded based on which environment (prod, dev, beta...) you're running the application, but I don't recommend this. Let's create a `.env` file at the project root directory.
```env
VARIABLEA=a
NEXT_PUBLIC_VARIABLEB=b
```
There is two kinds of variable, the public one that gets exposed to the browser and the API, the default one that only gets exposed to the API. :warning: So be careful when adding the `NEXT_PUBLIC` prefix because that's what makes a variable _public_.

## Conclusion
You have everything you need to create your next Next.js application with your React background.

In this article, we've:
- [x] Setup a new Nest.js project
- [x] Explained project architecture
- [x] Create a new page
- [x] Created links between pages
- [x] See the image module that optimizes image rendering
- [x] Explained the huge data fetching system
- [x] Created API endpoints
- [x] Used environment variables

If you liked this article and you want to go further, please reach out, and let's see together what could be interesting to discuss on! 


Built on top of React, Next.js is a full-stack web framework created in 2016 by Vercel. Its goal is to offer the best developer experience with all the needed production features.

Construit sur la base de React, Next.js est un framework web full-stack créée en 2016 par Vercel. Son but est d'offrir la meilleure expérience de développement incluant toutes les fonctionnalités nécessaires à la production.

How to understand Next.js when coming from React?

Comment comprendre Next.js quand on vient de React ?

## What a monorepo is?
If you still didn't hear about mono repository despite all the articles on the subject, then you live in a cave.
A mono repository is a repository that contains every project or sub-project of a structure.

The other way to maintain projects under a version control system (VCS) is to split projects into different repositories.

Do you see this forest picture? it's my mono repository and every tree is a subfolder containing a project.
In comparison, having multiple forests that contain only one tree, is a multi-repository architecture.
I am not going to compare the two ways of managing projects for two reasons:
- It depends on what you want to achieve
- Internet has plenty of articles speaking of this subject (:warning: a lot of these articles are biased)

## The Example
Considering this project tree:
```
nodejs-monorepo-example
 ┣ packages
 ┃ ┣ api
 ┃ ┃ ┣ index.js
 ┃ ┃ ┗ package.json
 ┃ ┣ maths
 ┃ ┃ ┣ index.js
 ┃ ┃ ┗ package.json
 ┃ ┗ website
 ┃ ┃ ┣ index.js
 ┃ ┃ ┗ package.json
 ┗ package.json
```
Note: To make it simple, we'll be using pure Javascript here. But the same is doable in Typescript, in fact, this website has been built using this architecture in Typescript.

We have one `packages` folder containing every sub-project. `maths` package will contain cross-package sharable code.

In order to generate `package.json` file, you can use `npm init`. Replace `npm` with your favourite package manager (yarn, pnpm, etc.).

## The differents ways
There are multiple ways to achieve a monorepo architecture in Node.js, from what I know there are three simple methods :
- [NPM workspace](https://docs.npmjs.com/cli/v7/using-npm/workspaces)
- [Yarn workspace](https://classic.yarnpkg.com/en/docs/workspaces/)
- [Pnpm workspace](https://pnpm.io/fr/workspaces)

I tried using the first two solutions, but they most likely will not fit all needs.
You are free to use one of these three methods. However, I'll show you how to set up the workspace only on `pnpm`.

## The proper way
[pnpm](https://pnpm.io/fr/motivation) is a package manager made in Typescript that focuses on performance, efficiency and (guess what?) monorepo! :tada:

`pnpm` offers [many installation methods](https://pnpm.io/fr/installation). I assume you already have a package manager: `npm install -g pnpm`.

Let's create a workspace definition file `pnpm-workspace.yaml`:
```yaml
# pnpm-workspace.yaml

packages:
  - "packages/**"
```
In our example, this file isn't needed because by default `pnpm` assume all packages of all subdirectories are included.

The next step is to name our `packages`. Edit all `package.json` files and make an alias name so you remember it's an internal package:
```json
{
  "name": "@example/maths",
  "version": "1.0.0",
  "description": "An internal maths package",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "IzioDev",
  "license": "ISC"
}
```
Now, we can share the code located in one package with another package. Try to run `pnpm add @example/maths` while you're in `/packages/website`.

:thinking: It's weird, it's not saying that the package wasn't found on the `npm` registry. Yes, correct, by default `pnpm` look all over your packages before looking for an `npm` package.
You can check this assertion by running `pnpm add @example/test` and how it's looking for an `npm` package.

Let's check the website `package.json` file:
```json
// packages/website/package.json

"dependencies": {
  "@example/maths": "workspace:^1.0.0"
}
```

It created a new dependency with a `pnpm` syntax. But don't worry, if you need these packages to be published on the `npm` registry, at publish time, this dependency would become :
```
"@example/maths": "^1.0.0"
```

Note: Since now, we've only used Common JS, However, if you want to use ESM, just add `"type": "module"` to all package.json so that `node` can know it's an ES module.

We can now create an exported `add` function into `/maths/index.js`:
```javascript
// packages/maths/index.js

// Common JS
const add = (a, b) => a + b;

module.exports = {
  add,
};

// Or, ESM
export const add = (a, b) => a + b;
```
Edit `/website/index.js` to import our freshly created `add` function:
```javascript
// packages/website/index.js

// Common JS syntaxe
const add = require("@example/maths").add;

// Or, ESM syntaxe
import { add } from "../maths";

// Use the imported function
const result = add(1, 2);

console.log(`The result is: ${result}`);
```

Since we're lazy developers, we don't want to change directory to `/packages/website` every time in order to run the entry file, right? So let's tweak our `package.json` at the project root directory:
```json
// package.json

"scripts": {
  "start:website": "pnpm -C packages/website start"
}
```
The `-C` option is to tell `pnpm` we want to run the command on another path, so here: on `packages/website`, and we're running the `start` command, as you would probably do using `npm`.

Ok, let's try this all together `pnpm start:website` at the project root directory will output:
```
The result is: 3
```
No really? :thinking: Thanks node for being so smart.

## Conclusion
Well, you have everything you need to set up a Node.Js monorepo and manage your internal packages properly.

In this article, we've:
- [x] Installed pnpm
- [x] Seen the different ways (npm, yarn, pnpm workspaces)
- [x] Created a pnpm workspace with multiple packages
- [x] Made a package dependent on another
- [x] Created an utility script at the project root to make our life easier 

## What's next?
In order to go further, you can try publishing your packages on a registry using the [pnpm publish](https://pnpm.io/fr/workspaces#publishing-workspace-packages) command. 

Managing a Node.js mono repository is not simple. There is a lot of tools to solve this problem. But what is the proper way to actually succeed in creating a mono repository project?

Gérer un repo en Node.js n'est pas facile. Il y a beaucoup d'outils existants qui permettent de résoudre ce problème. Mais quelle est la manière la plus propre pour gérer un monorepo ?

IzioDev

Je suis Romain Billot

À propos

Bonjour,

Mes compétences

Front End

Back End

DevOps

Prestations

Design

Publicité

SEO

Maintenance

Support

Parcours

2018 - PrésentFreelance chez IzioDev

2022 - PrésentLead Développeur Fullstack chez Harvestr

2021 - 2022Lead Développeur Fullstack chez 360Medics

2019 - 2021Développeur Fullstack chez Bilik

2019 - 2020Licence professionnelle - Web Application

2016 - 2019Licence Mathématiques et Informatique

Blog

Prenons contact