From Domain Modeling to Deployment: Building a MERN Application Without Getting Lost
Let's explore the different stages of the development cycle of an app through a real use-case that illustrates the foundational parts of any web application.
Building and deploying a custom solution to a problem involves many steps, but first, you need to understand the real problem and the operational system. That approach is called Domain Driven Design (DDD).
To illustrate these stages, I will use a recently deployed app I built for a local business: a car upholstery shop for which I had previously built a website, before the rise of AI-assisted development.
Stage 1: Problem Definition & Domain Modeling
The first task is to try to define what you will do. At this point, it's really useful to work with the final users. Define the entities, relations, and sketch a UI to interact with them. This is not a definitive decision, it's a guide, but you need to start somewhere.
In our case, we identified four entities, and we decided to keep the relations unidirectional: a Budget will link to Clients, Services and Car Models. Our app will work around those entities; with stats, CRUD operations (create, read, update, delete) and some additional ones, such as entity merging. Besides, we will add a calendar, print templates, WhatsApp links and other UX features.
In this stage it's also worth to define the invariants, conditions that should always remain true; e.g. a budget should contain a list of at least one non-duplicated services.
Stage 2: Choosing the Stack
In the second stage, you need to define a stack. In my case, I decided to go with the classical MERN stack (Mongo, Express, React, Node) plus MUI (Material UI) for fast frontend User Interfaces. A relational SQL database could have done the trick, but I preferred to go with Mongo to make use of the easy-to-deploy free tier of Mongo Atlas. It's a battle-proven stack anyway.
The Backend Architectural Layer
As an entry point for development, It's a good idea to begin with the backend logic. It will define your UI needs and will help you populate your database, which initially starts as a simple connection URI.
Some otf the tool I used were:
Mongoose: A popular library that allows you to create Schemas (rigid templates) for MongoDB entities, and provides you with a set of useful methods and hooks, pieces of code that can validate and manipulate data before and after the interaction with the db. An important concept to keep in mind is the difference between query operations (data here is the query itself) and document operations (data here is the document itself, the db object, like a particular budget in my case). This is where you can use hooks to validate data. Mongo scales really well with indexes for fast querying.
Express: Helps you manage the routes, api endpoints and the overall node requests and responses lifecycle. You can add middleware (hooks) and it helps you handle asynchronous errors and connection failures. You can also use Postman to test your endpoints.
The complete idea of the backend is to provide an API (a collection of urls or addresses) for the frontend to connect to, to manage the logic and to connect to the DB (persistance layer).
An optional tool is worth mentioning:
- Docker: It allows us to run our application in containers, standardizing the environment in which it runs, solving the "it works on my computer" problem. Although it's not strictly necessary, it is if you want to do atomic complex operations with MongoDB in local, so is a very common tool in the industry. I made a post about it here.
In our case, the merging operation was a complex one that needs to be atomic. You have to edit documents, delete some, travel and modify the budgets, etc. All changes should happen or none of them; a complete roll-back is needed if any of the steps fail.
The Frontend & UI Layer
React is a library built on top of JavaScript. Using it, your frontend app becomes a collection of components with their own state. With it, in combination with React Router to manage URLs and avoid refreshing the complete app on every request, plus Material UI, you can develop your app in a really fast way.
For the budget part, we created an incremental rendering form, where more fields are revealed only after entering a valid car plate and selecting a client.
On top of that, I used express-sessions, linters, formatters, and TypeScript as a language ( JavaScript with a type system ).
In these pictures we can see the incremental New Budget form in Spanish. Some UI features have been chosen by the client to make it faster to scan.
The Deployment Strategy
The deployment was really straightforward. I chose to use an Apache server with CPanel because my client already had hosting and it makes no sense to use a more sophisticated tool for a single user with fewer than a hundred requests per day. It was really useful to deploy both the backend and frontend in the same subdomain to avoid cors (cross-origin resource sharing) errors.
Having secured the application with express-session and critical security settings before deployment, the live app was ready and completely safe for production use.
Some Thoughts on "Vibe Coding"
I sincerely don't vibe code my apps. I'm not sure you can reallistically vibe code an app that involves Docker, transactions, business requeriments and deployment. But for people who are new to programming, I recommend not blindly vibe coding but to use AI as a senior consulting partner.
Try things, make tests, figure out why and how things happen, because that way you'll be creating the foundational blocks that will allow you to expand your systems knowledge for future projects.
As always, thanks for reading, and I'd love to hear your thoughts and comments.
