ex-mark1

Alright people, time for a story.

So yesterday — June 28th, 2025 — I sat down to build tda-merch, a nice full-stack e-commerce app. MERN stack, obviously. I set up both frontend and backend folders, started scaffolding code, added a few routes, even wired up JWT auth on the backend.

The plan was simple: get product routes working and move on. But then, mid-flow, it hit me — “this architecture is absolute chaos.”

It wasn’t even bad code — just messy. Unstructured. Zero isolation. The kind of setup that works... until it doesn't. That’s when I paused, sipped my black coffee, and thought:

“Well, I need to fix this before it turns into a full-blown disaster.”

So instead of duct-taping tda-merch together, I spun off a separate project — ex-mark1 — a clean, standalone e-commerce API built the right way from the ground up.

---

What is ex-mark1?

ex-mark1 (short for express-mark1) is a monolithic e-commerce API built with Express.js, TypeScript, and MongoDB — structured feature-wise, not layer-dumped, with clean separation between controllers, services, and models.

Basically, the kind of backend you’d want to plug into a frontend — not one you tiptoe around because it might explode.

It’s not just a throwaway backend for one project. It’s an API you could actually reuse, extend, or plug into multiple clients — a proper standalone service.

---

The Real Problem I Wanted To Solve

tda-merch made me realise: I didn’t fully understand how to design APIs — I was just writing them.

Sure, I could spin up routes, do basic auth, and ship features. But I wanted more clarity on:

• How do you structure a backend so it doesn't fall apart after 10 features?
• How do standalone APIs actually get built?
• What makes some APIs a pleasure to work with and others... not?

ex-mark1 is my attempt to answer that by building it from scratch — with real patterns, actual structure, and no rushed "will fix later" hacks.

---

Feature-Based Design (No More File Jungle)

Instead of throwing everything into /routes, /controllers, and /models, I’m going with feature-first structure.

So each domain (like auth, users, products) lives in its own folder, with its:

• controller
• service
• validation
• model
• routes

Everything scoped and co-located. If I want to work on products, I go to /features/products. That’s it.

No jumping across 4 folders to figure out who’s doing what.

---

Tech Stack (No Drama)

• Node.js — solid, nothing fancy
• Express.js — it’s not trendy, but it works
• MongoDB + Mongoose — easy to iterate, flexible, good enough
• TypeScript — because runtime errors at 3 AM are not a vibe

---

The Plan

The roadmap follows the usual e-com flow:

Auth → Users → Products → Cart → Orders → Payments → Reviews

Right now as of 5PM :

• view commit

• ✅ Auth with JWT is working
• ✅ Basic user flow is done
• 🛠️ Products coming up next
• 🔜 Cart and everything else once the base is strong

Along the way, I’m documenting it all — not just the what, but the why. Real architecture notes, breakdowns, mistakes, and patterns that made the code better (or worse).

---

Why Bother?

Because writing APIs is easy. Designing them isn’t.

ex-mark1 is where I pause, slow down, and figure it out properly. Once it’s solid, I’ll plug it back into tda-merch or wherever else I need it — this time with confidence, not chaos.

If you’ve ever looked at your backend and thought “why is everything broken even though nothing’s broken?” — this one’s for you.

---

Aright People It's 9:36PM

Just finished the products feature in my e-commerce API. Unlike auth and users, which use function-based services, I tried a class-based approach this time. Felt like experimenting — and I don’t like writing the same kind of code over and over.

So I built a ProductService class with methods like createProduct, listProducts, etc. Instantiated it where needed instead of calling plain functions.

Not gonna lie — it felt cleaner. Logic sits in one place, easier to inject dependencies, and it opens the door for stateful behavior if needed. But yeah, it does add a bit of boilerplate. Also, switching between styles isn’t exactly smooth.

Still, this isn’t production. Mixing styles here helps me understand what scales better. Might stick with classes if it holds up. If not, no drama I’ll rip it out.

End goal: clean, testable, scalable code. Don’t care if it’s a class or a function — if it works and reads well, it stays.

But now i have to ask myself do refactor auth and users to my new style or what ? It's just a side project let's just leave it like this, why not, right ?

---

Well now It's 10:24 PM

The caffeine I slammed two hours ago is fading, and so am I — but not before finishing the orders module. Same structure as products, sticking to the class-based pattern like a loyal framework simp. Controllers handle the HTTP noise, services do the lifting, models keep their mouths shut and talk to the database. Everyone knows their role. No surprises. No drama.

What’s funny is how natural it felt this time. No internal debates, no "should this be a function?" spiral. I just built it. Like muscle memory wrapped in TypeScript. Maybe I’m finally getting consistent — or maybe I’m just too tired to overthink it.

Watching the codebase grow like this is weirdly satisfying. It started as a playground, now it’s starting to look like something that could survive production. Not quite enterprise, but at least it won’t set itself on fire if I look away for five minutes.

Anyway, I’m done for the night. Eyes are heavy, caffeine’s ghosting me, and the code’s stable enough to not embarrass me tomorrow morning. I’ll call that a win.

---

And here we go again June 30, 2025 05:47 PM

• You know what I just realized I might have to create a shortcut for inserting time and date when i'm writing articles

Well anyways, here's the thing, I've created a lot of shit today and yeah i'm not maintaining good commit messages any more in the repo just putting it out there with somewhat decent commits, It's a headache guys... So over the past i think ten hours i've shipped all the features of our cool API and it is close to complete email service is almost finish and only tests are left or so i though and realized we don't have a notification feature , You know how it is you're just about to finish a project and suddenly you think of new features to add.

I didn't want notifications at first but now i want them, I'll have to implement and i was about to commit the directory structure and i get a call guess what I got a job offer I told them what i could I'm not really good at talking good about myself it was bit wired but I think it went well. read more about this assignment.