The Architectural Evolution: A Structural Deep Dive
To understand how I build systems today, we have to look at the structure. Below is the “Tree” view of my transition from a traditional MERN Monolith to a modern, Edge-Native Modular system.
1. The Legacy Architecture (BazarBhai)
This follows the classic Layered Monolith pattern. Logic is separated by technical function (all models together, all routes together).
bazarbhai-backend/ (The Monolith)├── src/│ ├── config/ # Environment-specific settings│ ├── models/ # Data definitions (MongoDB schemas)│ │ ├── userModel.js│ │ └── productModel.js│ ├── routes/ # API Endpoints│ │ ├── userRoutes.js│ │ └── productRoutes.js│ ├── middleware/ # Security & Auth (Global)│ │ └── checkAuth.js│ └── helper/ # Business Logic (Scattered)│ ├── order/ # Logic detached from the API layer│ └── products/└── server.js # Central point of failureThe Flaw: As this grows, it becomes “Spaghetti Code.” If you change a field in userModel.js, you have to manually search every file in helper/ and routes/ to make sure it doesn’t break. There is no automatic safety.
2. The Modern Architecture (TrackFlow)
This follows the Modular Edge-Native pattern. Logic is separated by feature (everything about ‘Events’ is in one folder).
trackflow-backend/ (The Modular Edge)├── src/│ ├── app/ # Application "Bootstrap"│ │ ├── register-routes.ts│ │ └── create-app.ts│ ├── db/ # The "Source of Truth"│ │ └── schema/ # Drizzle Schemas (SQL)│ │ ├── user.ts│ │ └── event.ts│ ├── modules/ # Domain-Driven Modules│ │ ├── event/ # Fully self-contained feature│ │ │ ├── event.routes.ts # Definition│ │ │ ├── event.schema.ts # Validation (Zod)│ │ │ ├── event.controller.ts # Orchestration│ │ │ └── event.service.ts # Business Logic│ │ └── site/│ ├── queue.ts # Background Worker (Edge-Native)│ └── index.ts # Global Edge Entry Point├── wrangler.jsonc # Cloudflare Infrastructure Config└── drizzle.config.ts # Database Migration ConfigThe Strength: This is Type-Safe.
- If I change the
event.tsdatabase schema, TypeScript immediately shows me errors inevent.service.ts. - OpenAPI Integration: The structure in
modules/allows me to auto-generate documentation.
Comparison: Why I Switched
| Feature | BazarBhai (Old) | TrackFlow (New) |
|---|---|---|
| Logic Placement | Scattered across helper/ and routes/ | Encapsulated in modules/[feature]/ |
| Data Validation | Manual checks inside functions | Automatic via Zod-OpenAPI |
| Deployment | Single Server (Limited) | Edge Network (Global/Cloudflare) |
| DB Handling | Non-relational (Risky data drift) | Relational SQL (Drizzle ORM) |
Summary of my Design Goal
I design for predictability. By using a modular tree structure like the one in TrackFlow, I ensure that a client’s system is easy to upgrade, impossible to “break” by accident, and runs with zero latency on the edge.