I've spent the last eighteen months using NestJS. I can simultaneously call it a good step forward in the Node space and something I wouldn't use for a new proj

I've spent the last eighteen months using NestJS. I can simultaneously call it a good step forward in the Node space and something I wouldn't use for a new project. They've done a lot of work to build a system that, so long as you stay within very narrow lines and don't ask too many questions, feels very cohesive and consistent. The unfortunate part is that it shakes apart at speed if you don't do both of those things. People make a lot of hay about the NestJS dependency injection system, and my intuition is that a lot of it is that it's a novel concept to a lot of the folks running into it. If you come from a Spring or related background, however, I think it's pretty clear that NestJS has a pretty critical misunderstanding of dependency injection. Modules are hardwired together--`BarModule` requires `FooModule`rather than just declaring what they need and what they export and allowing the dependency resolver to figure it out regardless of what module they come from. As-is, you cannot replace a dependency coming from `FooModule` with one, say, from `Foo2Module` without changing every consumer. It's a high-boilerplate devolved service locator rather than dependency injection. "Pretty critical misunderstanding" has become my default description of big parts of NestJS as I've gotten deeper into its use over the last year and a half. This description really does fit a lot of aspects of the system. It often feels as though the implementors read half a description of this or that, decided "that's a great idea!", and then implemented that half-a-description...poorly. The "microservices" concept (really just RPC, and not particularly play-nice-with-others RPC) is a good example, as is the really clunky access to WebSockets. CQRS is another prime example, as they've somehow implemented single-node CQRS, made it impossible to distribute, and declared victory and went home. It is better to not provide official support for something if that official support is going to be so full-stop awful, because that official support will choke out attempts to innovate in the space because you've already taken the mindshare for the problem at hand. Which dovetails into the problem that will probably end up putting NestJS in the dustbin as soon as somebody else comes up with a competitor: the NestJS team seems to have what feels like at best an oblivious and at worst a rivalrous relationship with their community and with Node as a whole. Over the last year they've rolled out what read to me as lock-in, don't-play-nice-with-the-ecosystem-as-a-whole "features", like their poorly intentioned CLI "monorepo tooling rather than just using lerna for multi-modulestuff like the rest of the world. Also like the future-forecasted "Nest CLI plugins" for things like linting otherwise bonkers misbehaviors[0]. As somebody who's written a bunch of open-source modules for NestJS, I consistently get the feeling that Kamil would really prefer it if developers just shut up and took his stuff and made apps (maybe paying him along the way?), rather than building their own open-source stuff alongside it. I still have a very bad taste in my mouth from the way that they just stomped on the `nest-schedule` project by added a less-featureful but otherwise identical "cron-like" gizmo to NestJS core without so much as a nod to the community member who wrote the better one before they did. The idea seems to be that NestJS isn't a community, it's a single-source vendor, and in 2020 that's weird to me. I've used a lot of NestJS but I can't really countenance using it for new projects, and I can't recommend it to others. [0] - https://github.com/nestjs/nest/issues/3279 https://github.com/nestjs/nest/issues/3279