Building Next.JS Apps That Scale — 1

(NOTE: This article assumes you have at least an intermediate knowledge of building NextJS apps. If not, you can get started here, and come back to this article later)

Working as a developer, if you are interested in building large scalable apps you will eventually end up working on a team, where everyone has their own coding styles and editor choices. Your goal as a team should be to maximize your output collectively towards actually building the product, and not spend half your time talking with each other trying to get up to speed with each other’s say variable naming conventions. Thus it becomes essential to agree upon a set of rules before starting the project, which the team will stick with throughout the build. Even if you are alone working on a big project, it becomes essential to have a framework which you will stick to so that your time is not wasted 1 month from now trying to figure out that function you wrote today.

In this article we will look at how to set up a NextJS project with a few basic rules so that it has a consistent structure no matter how big it gets. This is by no means an exhaustive article, and many companies do have their own proprietary tech to implement their own custom pre-agreed rules, but here we will look at a few open source frameworks which will basically introduce the concepts.

So we start off with a simple NextJS project here.

npx create-next-app scalable-template

Engine Locking

The first thing we do is specify the node version we built our project on, and ensure that it is adhered to across all development environments. We don’t want to be building on Node 18 only for it to run on Node 14 in the production environment and breaking. There are 2 ways to approach this: either using the .nvmrc file or “engines”.

.nvmrc

This is useful for projects where a version manager like nvm is used. ‘nvm’ will scan the project file for the .nvmrc file, and install the node version mentioned there.

Engines

Here we specify a .npmrc file and also an “engines” field in package.json. Personally, this is my favorite approach because along with locking the node version, it also allows me to lock down either npm or yarn as the package manager. Mixing them up can lead to error messages down the line, or outright bugs where you’ll probably need to delete the entire node_modules folder and install it again. We’ll not go into the yarn vs npm debate here, the critical thing is to choose one and consistently stick with it.

This is all we need to put in the .npmrc file. Without the engine-strict argument, a warning will be logged in the console but the installation will proceed with other(potentially breaking) versions of node.

Add this snippet in package.json, basically specifying the node and npm versions we want the project to be using, along with the error message shown if we run yarn

With the configuration we have here, we’ll basically run into the following error if someone runs yarn install in our project.

It is a good idea to have both the above things in your project.

Git

With those things sorted out, now is a good time to set up Git to keep track of project changes. It will be out of scope of this article to go into the benefits of Git, but to me personally the most important benefit is being able to make changes to your build and running it independent of the production build, fixing the errors and only then merging those changes into production. For now, just run git init from the root of your folder and an empty git repo will be initialized. Then run git add . and git commit -m "init" to make the initial commit to the repo.

Conclusion

We’re 25% on our way to build a consistently reproducible NextJS app that scales. In the next part, we will be looking at incorporating standard code refactoring practices. We will also be setting up certain pre-commit hooks in our Git framework to ensure basic things like commit messages follow a certain descriptive format and we don’t accidentally commit breaking changes to production.