Next.js

02What it takes care of

A business application needs the same basic parts again and again. Next.js provides them, so a project starts with the structure in place and the time goes into the parts that are specific to the client.

• Pages and addresses: every page has its own address, such as /invoices or /customers/42, and the folder structure of the code decides which address shows which page.
• Server code: functions that run only on the server, for example to read from the database, check permissions or call another system's API.
• Rendering: pages can be prepared on the server and sent to the browser ready to show, either fresh for every request or prepared once in advance.
• Sign-in and access checks: Next.js has fixed places where an application checks who is signed in before a page or a function runs.
• Delivery: images are resized automatically, code is split into small pieces, and only what a page needs is loaded.

03How a page is built

When someone opens a page, Next.js runs the code for that page on the server. That code reads the data the page needs, for example the open invoices of one customer, and React turns it into the finished page. The browser receives the page ready to show and then takes over, so buttons, forms and filters react immediately.

Data that a screen does not need stays on the server. If an invoice record contains an internal note, the browser never receives it unless a page is written to show it. Passwords for databases and keys for other services are only ever used on the server.

Pages whose content rarely changes, such as this article, can be prepared once when the application is built. Next.js then serves the finished file, which is about as fast as a website can be.

04An example from a business application

Take a customer portal where clients see their open tickets and download invoices. In Next.js this is one project with a few folders: one page for the ticket list, one for a single ticket, one for invoices, and a server function that creates a new ticket when a client submits the form.

The ticket list is rendered on the server, after a check that the person signed in belongs to the company whose tickets are being shown. Downloading an invoice goes through a server function that checks the same permission before it hands out the file. The code for these checks sits next to the pages it protects, which makes it easy to review.

05Alternatives

Several frameworks solve similar problems. Each is a reasonable choice in the right setting.

• Remix and React Router: also built on React, with a different approach to loading data and forms.
• Nuxt: plays the same role for Vue, another library for building screens.
• SvelteKit: the framework for Svelte, which needs less code in the browser.
• Angular: a complete framework from Google, common in large companies.
• Classic server frameworks such as Laravel (PHP), Django (Python) or Ruby on Rails: they render pages on the server and are strong for data-heavy applications, with a separate language from the browser code.

06What to look out for

Next.js itself costs nothing. The costs come from hosting, and they depend on how much the application is used. For an internal tool with a few dozen users they are usually small; for a public site with a lot of traffic they need watching.

Next.js moves quickly. A new major version appears roughly once a year, and older applications have to be updated now and then. That is normal maintenance, and it is easier when the application has automated tests.

Some features work best on Vercel's own hosting. Next.js also runs on other providers, for example on Microsoft Azure, AWS or a company's own servers, but a few conveniences have to be set up by hand there. It is worth deciding on hosting early.

07How we use it

All our applications are Next.js projects, this website included. We write them in TypeScript, build the screens with React and keep the data in Postgres.

We usually host on Vercel in Frankfurt, in an account that belongs to the client. Every proposed change to the code gets its own preview address, so a change can be looked at in the browser before it goes live. Our automated tests check on every change that the application still builds.

Frequently asked questions