Mohit Upadhyay

Posted on Dec 3

CRUD Isn’t a Lifestyle: Stop Turning It Into a Spiritual Journey

#node #express #backend #mysql

Let’s clear something up.

CRUD is not a religious ritual.
It’s not a PhD thesis.
It’s not the final exam before you become a Senior Engineer™.

It’s four actions:

Add a thing
Fetch a thing
Modify a thing
Remove a thing

Yet somehow developers manage to turn this into an intergalactic architecture conference.

Give someone a simple Express + MySQL task, and suddenly you’re staring at folders inside folders inside folders like you just opened a Russian nesting doll of “why?”

Symptom #1: The Onion Architecture That Nobody Asked For

A normal person:
“Can you save this user?”

A developer with too much time:
“Absolutely. First, let me introduce our 19-layer pipeline.”

And now your humble CRUD is wrapped in:

A controller
A service
A handler
A repository
A provider
A manager
A coordinator
A mysterious *utils * folder that everyone is afraid of

All so we can put a name and email into a table that has… two columns.

Congratulations, you have architected a sandwich.

Symptom #2: The ‘One Day We Might’ Disease

MySQL today.
Mongo tomorrow.
Postgres in our dreams.
Neo4j if our tech lead gets bored on a weekend.

And because of that hypothetical fantasy migration:
"You now have a database abstraction thicker than a phone book."

But let’s be honest:

Your schema isn’t portable
Your queries aren’t portable
Your team isn’t portable
Even your tech lead isn’t portable

If the database ever changes, you’re rewriting everything from scratch anyway.
Your abstraction layer?
That thing is going straight into the trash with the sprint leftovers.

Symptom #3: Turning Validation Into a Broadway Production

Form with three fields?
Cool. Should take 10 minutes.

But no.
We get:

Input schemas
Pre-schemas
Post-schemas
Meta validation pipelines
“Error sanitizers”
A whole philosophical debate about whether IDs are truly integers

Buddy.
It’s an email and a password.
Calm down.

Symptom #4: The Generic CRUD Base Class Catastrophe

A developer discovers inheritance and suddenly every resource in the system must “extend” a universal CRUD class.

At first it sounds genius:
“Everything will be reusable!”

Until every resource has slightly different rules, and now the base class looks like:
“If it’s a user: do this.
If it’s a product: do that.
If it's neither: pray.”

You didn’t reduce duplication.
You invented a glorified switch statement wearing a tuxedo.

So What Should CRUD Look Like?

Brace yourself.
This is controversial.

Just write it.

Yeah.
Directly.
In plain English.
No mystical abstractions.
No 47 folders.

A route handles the request.
A service does the work.
The database stores the data.

That’s all a CRUD needs to be.
You wouldn’t put a fork inside another fork just to eat food.
Don’t wrap CRUD in unnecessary layers.

But What If My App Grows?!

Then you refactor.
That’s the secret.
There is no prophecy demanding you predict every possible future requirement like some backend fortune-teller.

Write code that’s easy to improve, not code that tries to impress the ghosts of architects past.

Good CRUD is boring.
Boring is good.
Boring means everyone understands it.
Boring means your onboarding isn't a hazing ritual.

When Structure Actually Helps

Not all structure is evil.
Use it when it reduces noise, not when it increases suffering.

Good reasons:

You have cross-cutting rules (logging, soft deletes, permissions)
You genuinely reuse logic across multiple endpoints
The logic is complicated enough that it deserves its own home
You need real contracts, like in SDKs or shared libraries

Bad reasons:

“My code looks more enterprise this way”
“I saw a YouTube video about hexagonal architecture”
“Our app might scale”
“It feels cooler”

Final Thoughts

CRUD is not where genius happens.
CRUD is where clarity happens.
It’s the salad of backend engineering: simple, healthy, and not worth reinventing.

Save your creativity for parts of your system that actually deserve it; Not for wrapping a basic insert operation inside a spiritual quest for architectural enlightenment.

Make CRUD clean.
Make CRUD readable.
Make CRUD boring.

Your team will thank you.
Your future self will thank you.
Your database doesn’t care, it just wants the data.