How to optimize your MERN workflow with a solid architecture

We've probably encountered a MERN stack project on the internet that was perhaps the messiest thing we've seen. Where everything was crammed into one single file. Where the front-end and back-end logic were squeezed together, files and variables have random names, making the codebase hard to explore and no error handling whatsoever.

This is why a strong foundation has to be created before developing a MERN stack application or any other type of application for that matter.

A disorganized project structure can easily turn an app into a mess. With a proper template, you can develop an application that is functional, scalable, manageable, and easy to work with.

Following standard practices can considerably improve the developer experience and code quality. Let's dive right in.

Principles of project structure

Before we go into these principles, here are some best practices you should follow to improve code readability and make your project easier to maintain.

Best practices

1. Data management is the proper handling of data flow and status.
2. Use Linting and formatting tools to enforce code standards.
3. Use version control like Git and Bitbucket to manage your code.
4. implement unit tests to be able to find issues early on prevent unpredictable behavior from your code and ensure code stability
5. Error management requires putting in place robust error-handling procedures.

Separation of concerns

Separation of concerns or SoC, is an essential concept in programming that recommends breaking down a huge system into smaller, more manageable components, each with a role. Such as separating the Front-end from the Back-end.

Organization

Creating a directory structure with consistent naming convention. Component-based architecture requires breaking down the user interface into reusable components. Routing includes setting up effective navigation within the app.

Project architecture

This is how our project architecture should look.

project-name/
├── client/
│   ├── public/
│   │   ├── index.html
│   │   └── assets/
│   ├── src/
|   │   ├── services/
│   │   ├── components/
│   │   ├── pages/
│   │   └── App.js
│   └── index.js
├── server/
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   ├── middleware/
│   └── index.js
├── package.json
├── .env
└── README.md

`
Let's talk about each folder and file in our structure and their role.

Project Root

• package.json: Contains information about the project, its dependencies, and scripts for running the application.
• .env: contains environment variables like API keys and other information.
• README.md: is the project documentation.

Client Directory (frontend)

public

• index.html: The main HTML file for the application.
• assets: Folder that can contain images, fonts, and other static resources.

src

• services: For making HTTP requests to the backend using Axios or Fetch.
• components: Reusable components.
• pages: Main views or screens of the application.
• App.js: The main entry point for the React application.
• index.js: The entry point for the client-side build process.

Server Directory (backend)

controllers

• Contains logic for handling incoming HTTP requests and responding to them.

models

• Defines the data structures (schemas) for the database.

routes

• Defines the API endpoints and maps them to controller functions.

middleware

• Contains functions that process requests before they reach the controllers ( like error handling).

• index.js: The entry point for the Node.js server, typically responsible for setting up the Express app, database connections, and route handlers.

This architecture is MVC (Model-View-Controller) on the backend and component-based architecture on the frontend.

The MVC architecture has a clear division, the three components are interconnected and each is responsible for a different aspect of the application making it easier to maintain.