🏗️ Still Planning — But This Time It Actually Matters

Hey guys,

Still stuck in planning mode 😅. But these decisions may be more worthwhile than they seem.

🔀 The Monolith Decision

Monolithic architecture is simply a software development model where the entire app lives in a single codebase. Pretty much the traditional setup most beginner developers follow naturally without even realising it.

Microservices on the other hand is a distributed architecture where several individual services connect and communicate with each other to function as one application. Scalability is the main reason why microservices is so widely adopted — companies like Netflix, Amazon, Uber and Spotify all run on it. Imagine Netflix operating on a single server and a single codebase. Debugging would be a nightmare, maintenance would be chaos, and one bad bug could potentially take down the entire platform for millions of users. Not ideal. 😬

For me though, the choice was obvious — monolith. No plans to massively scale this app, a single codebase keeps things simple, and it's cost-effective.

Sometimes the boring choice is the right one.

📐 SOLID Principles

A great man named Robert C. Martin created the SOLID principles — giving us developers yet another thing to study😒. Just kidding, it's genuinely useful.

In short, following SOLID makes your code:

Maintainable — easier to update and refactor
Scalable — grows with fewer issues
Reusable — modular and decoupled
Readable — cleaner and easier to understand

There are 5 principles in total — S, O, L, I, D. I studied all five. I applied two.

And that was intentional.

Since my app is small with minimal business logic, forcing all 5 would just be over-engineering for the sake of it. Good principles applied in the wrong context are still bad decisions.

🤖 How Claude Helped Apply It

Once I studied the principles, I asked Claude Code to analyse my project and apply
SOLID to the planning. What it did was clean and practical.

For Single Responsibility (S), it wasn't just about separating files — it also
meant breaking down logic into focused modular functions rather than having one
function trying to do three things at once. Models only hold Mongoose schemas.
Routes only handle HTTP. Middleware only handles authentication. Nothing overlaps.

For Interface Segregation (I), it split the API folder by domain —
scheduleApi.js and authApi.js became separate concerns — so different parts
of the app only import what they actually need, rather than pulling from one
bloated module that knows too much.

For O, L and D — Claude explicitly flagged these as unnecessary for this project. The business logic is too minimal to justify them. The philosophy was
simple — use SOLID where it helps, skip it where it doesn't.

🙏 The Mentor Behind All This

None of this planning rigour came from nowhere. I have been fortunate enough to
have a mentor — a senior professional at GoDaddy — who has been guiding me
through these concepts completely voluntarily. Having someone with real industry
experience push you to think about architecture and principles before touching
code is something most student developers don't get. Genuinely grateful for it. ✨