
Clean and Consistent Express.js Controllers - stemmlerjs
https://khalilstemmler.com/articles/enterprise-typescript-nodejs/clean-consistent-expressjs-controllers/
======
eropple
I wrote _a lot_ of TypeScript just using Express, and it pretty much always
ended up looking kind of like this.

Today, though, I think this is reinventing the wheel for little benefit. I've
moved my own projects to NestJS ([https://nestjs.com/](https://nestjs.com/))
and have found myself paying a lot more attention to logic and application
behavior rather than structuring code around a too-thin web server.

NestJS uses Express or Fastify under the hood--because both are great web
servers!--but serves to make life a lot more pleasant when using them. The way
it strongly encourages the decoupling of application logic (services) and the
serving of data to clients (controllers) is a good one and, to me, does a
_much_ better job of creating an "enterprise NodeJS and TypeScript"
environment than rolling one's own.

~~~
stemmlerjs
I've been hearing a lot about NestJS recently. I've yet to try it out on a
Greenfield project.

Yeah, I'm totally with you on that. Frameworks have the structure we all need
but seem to neglect:) Although there is a lot of merit in learning by doing
(hence the purpose of the article and my website overall).

Lots of brownfield vanilla Express.js Node APIs can be improved using this
pattern.

------
serguzest
I love Typescript but as a recovering C# programmer, I try to stay away from
OOP in nodejs.

~~~
stemmlerjs
Object modeling is definitely not the easiest thing in the world, but for
complex problem domains, it can be what makes or breaks being able to
continuously push a project forward.

For simple RESTful todo apps, I'd definitely say you could get away without
objects.

But if I was to build a GitLab clone, it would be incredibly difficult to
model such a complex problem domain without using a domain model.

------
moltar
Why reinvent the wheel. Just use NestJS.

~~~
stemmlerjs
After further thought, because overarching opinionated frameworks sometimes
aren't the answer.

From an architectural POV, sometimes frameworks dont solve all your problems,
and sometimes they make things harder for you by going against the grain of
how your problem domain actually wants to be architected.

Knowing the basics of good software design and how to not use a framework if
you're not able to has a lot of merit.

Some domain driven development can actually be idealized as you building your
own framework of the problem domain. Why complicate that by adding an
additional layer of infrastructure?

It really does depend on the project and evaluating the framework.

