Clean and Consistent Express.js Controllers | Hacker News Reader

Clean and Consistent Express.js Controllers

khalilstemmler.com

14 pointsstemmlerjs6 comments

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/) 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.

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.

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

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.

Why reinvent the wheel. Just use NestJS.

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.

Reply on news.ycombinator.com