I Hate NestJS

> For a long time NestJS depended on class-validator ... and regularly suffers from security vulnerabilities that can take years to fix.

As a maintainer of class-validator, I'd like to clarify that this is not accurate. Legitimate security issues, when reported, are promptly addressed. The multi-year security alert listed in NIST NVD is akin to the bogus report that the curl maintainer discussed a few months ago.

In a nutshell, the report suggests that specific settings can potentially lead to validation bypass, which is indeed the case because these settings determine whether unknown objects should fail or pass the validation. This is analogous to my creating a CVE for Windows simply because anyone can access my computer when I haven't set a password.

However, the other part about the scare support is sadly true though.

I'll say it: NestJS is pure evil. It pushes OOP beyond its absolute limits. Not that I would consider OOP a good way to do things in general. Beyond misleading autocompletions that look helpful at first glance, it's usually somewhat counterproductive in any language and with any framework I have ever encountered. But NestJS manages to make it pure pain and sadness. It's like a framework that spins around its own "architecture" making it nearly impossible to get stuff actually done.

Pro tip: If you find a paragraph celebrating "SOLID principles" at the beginning of the documentation of something, run.

Storytime.

When the company I work for hired a person who was super excited about NestJS, I looked at it with an open mind (or so I'd like to think). I was probably a bit sceptical because this person, who seemed really nice, couldn't think of a single thing he disliked about it (that's a question I tend to ask about any tech that someone is all-over-the-moon about, and my thinking is that if you can't list a single thing you dislike about something, you probably don't know it well enough), but let's take a look at it!

As soon as I saw they had basically copy/pasted the Angular 2+ module system into Node.js, and went full-hog into IoC, I decided not to even try it out.

The same Angular 2+ module system that basically was copy/pasted from AngularJS and that I had actually ripped out of our huge AngularJS app at our previous job because it caused more friction than it solved, and lo and behold, the tests became simpler when we didn't have to use ngMock. All those services were singletons anyway and were more suited to being actual JS/TS modules.

But AngularJS had a valid reason for it because it was back in forever-ago and there were no JS modules, much less dynamic imports for code-splitting.

Not that you need code splitting for a backend app.

I have never felt I needed DI in a Node.js app.

NestJS - not even once.

I've been using NestJS this year and (mostly) found it great for the use cases I've had.

I'd rather describe the HTTP to method call mapping of my controller with decorators than a bunch of "add endpoint" calls. I like that the HTTP to code binding is located right beside the code itself.

I like that I can separate my app up into modules and couple them as loosely or tightly as I need.

You can architecture astronaut with NestJS, but you don't have to! I wrote a queue module (to interface with a legacy queue system), using decorators to specify the consumer. Docs on doing this are essentially nonexistent. The NestJS based library I cribbed from spread the "find the object & method to call" logic across multiple classes. I distilled it down to a screenful.

As with all tools, you get some choice in how you use it. Want to go wild with dependency injecting a zillion classes with one method each? If you really want to, I guess you can. Want to be sensible, for your definition of sensible? You can do that too.

Regarding TypeORM - recommending Prisma feels a bit like throwing out the baby with the bath water. If I'm reading their Github issues correctly, they are slowly starting to use JOIN statements in their generated SQL. It may be fine for an ORM to perform local joins during alpha, but anything after that really should use the features DBs provide for these kinds of basic things.

I've heard good things about Drizzle.

Finally someone said the words! NestJs always seemed like pure architecture astronautics, managing to be at the same time completely over engineered, and a copy of concepts from 2005 Java systems, in the worst way.

I have absolutely no idea why anyone would use NestJS, short of being used to writing dumb enterprise Java for the past 20 years or not wanting to move forward from it.

What a relief, I’m not alone feeling this way

RE decorators in TypeScript: it is true that TS code does not have to live in classes... in general. But some APIs (eg those for custom elements) _do_ require classes, so one may end up writing a whole bunch of classes anyway. And in this case, decorators are in fact quite useful.

I don't use Nest or have strong feelings about it, but this bit stuck out:

> TypeORM is not even typed. When you run a .findOne() method is just passes back a generic.

This is patently false. I'm not sure what the author is even trying to say here, but the output of `Foo.findOne(...)` is `Promise<Foo | null>`. If it's not, there's a good chance you're coloring outside the lines. Maybe this is true in the context of NestJS, but it is not true for typeorm on its own.

I'm very curious to hear from someone who likes DI in a non-OOP language - why? What techniques do you use to make the level of indirection feel like a help, rather than a hindrance, in your codebase?

Reading this article reminded me that DI has a lot of advocates, but I've never heard a compelling reason to use it in most codebases.

> That surface-level judgement is as naive and nubile as it gets.

Just a minor editorial comment... you might want to check the definition of 'nubile'

Both the original and this followup article both say:

"Last Updated: 1 year ago"

I would much rather see real dates, to get a feel for how long this change of opinion took.

(if you inspect, you see the actual date is 8/28/22, but the original doesn't show the original date, only the last updated date of the same day)

> NestJS is one of those things where people coming from other languages like Java don't know how to develop without the patterns that Java gave them.

This is EXACTLY how I felt using NestJS. Except, IMO, it took the worst part of Java (Spring DI, esp. the over-verbose, make-changes-in-4-random-files-to-get-an-object style they did it circa early 2010s, instead of the much cleaner styles they have today) and shoved it into a language that is built on a completely different paradigms and constraints.

Not had a single pleasant experience working with NestJS, especially once it hits a certain scale, and you are just bogged down running between modules, services, controllers and DI-hell

So...

Decorators are higher order classes.

Dependency injection (i.e. inversion of control) is not standard OOP.

DI is not the only way to do composition in OOP. OOP gives you the choice of both inheritance and composition. Look at any Python, Rails, or Smalltalk codebase and you will see that things are both composed and inherited.

This post is just a rant. NestJS doesn't work for you? Don't fucking use it, no reason to hate.

Nestjs is my least favorite framework I've used in the past 10 years. Just a step below RxJS.

It's an ORM which means performance you may as well forget it. It's such a memory hog. On top of GraphQL, which can easily cause performance issues on its very own without help thank you very much. It's like the N + 1 problem had a baby with a memory leak. Why devs keep doing this to themselves I'll never understand. You don't need this level of pain for even a massive API codebase.

I've done a lot of work with NestJS. I agree with some, but not all, of the authors points.

- TypeORM is pretty bad. Particularly when you start using it for more than simple crud operations. There was an epic battle in the GitHub issues and eventually some folks finally got through to the maintainer. Since then, development has picked up and some long-standing issues have been corrected. It's still pretty bad. However, I haven't found anything in the nodejs ecosystem that's substantially better, which is sad.

- class-validator and class-transformer mostly work, but are barely maintained and have many issues going back years. The maintainers left a bad taste in my mouth. I asked years ago about why these libraries which are so core to NestJS are not forked. The issue was locked with a frustrating response. It sounds like they may have finally been pursuaded to fork them.

- NestJS support is terrible. I understand they have a paid support service but if you don't subscribe to that, they lock, discard, ignore any issues raised, even if they are valid and significant. They push all support questions to Discord, and as far as I can tell, none of the actual maintainers look at it. Very frustrating.

- NestJS breaks semver by releasing breaking changes in minor or patch updates. They don't seem to understand that if a core third party dependency has a breaking change, they need to bump their major version.

- It's very difficult to understand what has actually changed between versions. And with the history of breaking semver, upgrading is just plain scary. The "release notes" are just the commit list, and to make matters worse, they don't use a monorepo so you have to search through a dozen repositories.

Unlike the author, I do actually enjoy the modular design, the dependency injection system, and a few other design choices. The only difficulty I've encountered when testing is around the third party pieces, such as TypeORM.

I believe the target demographic for NestJS are spring developers, not native JS/TS developers.

If you come from Java / Spring you would feel right at home, anyone else would feel disgust.

If you found this problems in nestjs then most of them should be in Angular as well. As it is explicitly told in the documentation that Nestjs is a copy of the frontend framework.

People miss the point of OOP as practiced (vs what the revered ancients intended).

Alan Kay wanted biology and we got it, just the taxonomy system instead of cell biology.

OOP with classes is a way to classify and organize code.

The problem with the functional paradigm is there’s less clear patterns for code organization.

Check out the average typescript project (or just any successful long lived js project) and the code organization is all over the place.

Not saying you can’t organize a function and module system, it seems like a bigger challenge.

Also not a fan of NestJS, having used it on multiple projects in past job.

I'll tell you what. If you must work with NodeJS, IMHO you are best off just keeping things light and simple.

NestJS is not good. I've used it professionally a few years ago for several services, and it was overly complicated which would be fine if the performance was okay - but it was not good either. And don't get me started on TypeORM or Prisma (or ORMs in general). So much wasted time and effort hammering down performance issues. The NestJS docs were also not that great and required having to dive into GH issues or source code too much compared to other frameworks.

I eventually rewrote the services to use express + kysely + zod + msgpack. There was clear separation of concerns with layers which made both unit and integration testing easy. IMO attempting OOP in JS comes with additional complexity/overhead and performance implications due to overly complex inheritance.

When in doubt, KISS.

He hates TypeORM but loves Prisma and Prisma can't even do joins, it's doing N+1 by default and always.

What does TypeORM do then?

I wonder what the alternatives are. I've searched for a framework that is a middle ground between bare-bones Express and NestJS. Something that I can throw a Zod validator at and it handles the validation for me by default, yet lets me structure my code a bit more functional and less opinionated than NestJS.

JavaEE has been using similar pattern for decades, somehow nodejs developers it's world changing and every startup on the planet is onboard with its ecosystem.

I feel that the only devs who feel at home with nestjs are angular devs since nestjs looks like angular retooled for server side work

> That surface-level judgement is as naive and nubile as it gets.

Nubile? Auto-correct mistake? Or just a very strange worldview?

I saw a recruiter trying to hire a dev with 7 years of NestJS experience the other day. It takes all sorts

I like the part on tests. No need for dependency injection when you can just override/spyOn the functions. Most people in the .NET world uses DI, causing a lot of smaller classes where code is dubiously grouped. And my god, all the interfaces where every use of that could just as well be the class version. But we have to use DI, because (1) people look at you like you're insane if you tell them you don't like it. And (2), we also don't want to pay for commercial software like JustMock (not affiliated) or VS Enterprise (also not affiliated), that supports mocking static methods. I think that in lack of a free, maintained and widespread library for this, C# ends up with the mess the author describes. It's a shame, because there's nothing wrong with the language itself.

Because of (1) it's a struggle to convince anyone to buy (2). And would be silly to expect someone to provide it for free.

Dependency injection is still tremendously helpful in writing unit tests.

Recently I did some work on a project that was originally built using the LoopBack Typescript framework [0], and it suffers from all of the same issues as NestJS. I wouldn't recommend anyone use either framework. There's really no need for dependency injection in NodeJS. The problems DI solves in other languages can be better solved in NodeJS by other means.

0: https://loopback.io/doc/index.html

Yea I refuse to use libraries which use(d) the old typescript decorators.

Javascript adopting the class keyword was really bad. What a bizarre language which added something as syntactic sugar in the language but it's a paradigm.