nest

s the programming model of those modules. Look at Nest.js as well: https://github.com/nestjs/nest/blob/master/packages/core/rou... The whole codebase of Nest.js looks an awful lot like Spring or ASP.NET (controller syntax) probably because there's a lot of crossover in terms of what APIs need at scale and how to logically organize that logic. It just so happens that most use cases for C# and Java favor applications at a larger scale. Another key difference being object scope and lifecycles -- something that rarely comes into play in the generally single-threaded Node runtime. This being one of the key reasons why dependency injection is a thing in C# and Java land.

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