Build it better: Next.js Directory Structure (For Large Apps).

In the previous iterations of this series we primarily focused on improving the developer coding experience, however in this post we are going to take a step back and focus on one of the fundamentals of a large scale project, the directory structure.

Please note that this is part of a series where I build up my new SASS business Core Supply. In the previous post we took a look at making the Next.js Code Splitting. so if you like this kind of real world scenario coding content, then please let me know in the comments and possibly consider following :)

What issue are we trying to solve?

Because Next.js is an all in one system, with the inclusion of a backend and frontend out of the box, there is a big issue with figuring out what goes where. For example, if we were to create a /utils folder then how would we know which utils are used in the frontend compared to the backend, or possibly even both. Therefore I have come up with the following structure in attempts to make the project easy to understand.

.
├── backend/
│ ├── config
│ ├── enums
│ ├── handlers
│ ├── models
│ └── services
├── common/
│ ├── config
│ ├── dto
│ ├── enums
│ └── utils
├── frontend/
│ ├── components
│ ├── config
│ ├── enums
│ ├── models
│ ├── routers
│ ├── utils
│ └── view-models
├── pages
├── public
├── styles
└── types

As you can see this still maintains the basic folder structure of a Next.js application but now there is better separation of the Service and Display layers while still being able to share commonality between the two.

Folders Explained

backend

• config: Constant data such as collection names or database details
• enums: Backend based enumerations such as
• handlers: API request handlers (see Next.js API Handler).
• models: Database models.
• services: methods to access or mutate data.

common

• config: Common constant data such as http response codes.
• dto: Data transfer objects used to send data from the backend to the frontend (this is a really beneficial “contract” to have). can also be used to receive data in a specific format.
• enums: Common enums such as a status code.
• utils: Common utility functions such as formatters or validators.

frontend

• components: All tsx or jsx components.
• config: Constant data such as route paths or http endpoints.
• enums: Common enums for application state such as loading.
• models: Objects required on the frontend.
• routers: All of the routers of your application. (See Next.js Router).
• utils: Utility functions such as http request handlers or formatters.
• view-models: View models for your application. (See Next.js Code Splitting).

Summary

This is by all means an opinionated folder structure but I felt that it was necessary to share in case others wanted to accomplish the same level of separation as I did.

In the end of the day it is important to find the directory structure that works best for you. The only recommendation I can add is to limit yourself to 3 levels because after you go over that threshold it becomes a little difficult to maintain.

If you would like me to discuss other folder structures then please let me know in the comments and I will be sure to add that in to one of my next posts!

If you have anything that you think that I missed or something that you think is incorrect then please let me know.

Until next time… Happy Hacking!