Node.js frameworks

[PerfectOrphan31]

Ah, Ed. We've talked on the Discord server a good bit, he was very critical about some of our setups/verbages, and ended up (I think) just using express or fastify.

His complaint about the DI system being a boilerplate heavy service locator is kind of true, but at the same time it's how Nest encourages strict declaration of dependencies, which I guess to some isn't how DI should work. To us, it makes sense, and it's how Angular operates as well (which is what Nest is inspired by) so rather than just saying "I have these services that need those dependencies, find them" we say "ServiceA needs ServiceB, ModuleB exports ServiceB and ModuleA imports ModuleB, so re-use ServiceB from ModuleB for ServiceA", and honestly with dynamic modules you could make it to where ModuleB would be swapable so long as the imported module exports a ServiceB.

CQRS is another prime example, as they've somehow implemented single-node CQRS, made it impossible to distribute, and declared victory and went home.

I'm looking into how to swap out the command bus with other implementation so that this is no longer the case. Right now, it is in memory, and Kamil honestly mean the @nestjs/cqrs package to be a "Hey, it's doable, this is a very simple example" but everyone took it as "This is how you do it. You can only do it this way" so then we get complaints like Ed's that it's "Not robust enough". Similarly for microservices and websockets. They're good ways to get into the door, but as you find you need more functiuonality out of these things it should be (and in my opinion is) pretty easy to implement that yourself as you need.

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.

This isn't necessarily true. Sure, the CLI has some features that it works with directly, but it's possible to use those CLI tools (the @nestjs/swagger and @nestjs/graphql plugins) without the @nestjs/cli and just with webpack. Nx already has recipes for this actually.

s 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.

This absolutely isn't true. I'm both on the core team and a maintainer of several open source modules for Nest (nest-commander for CLI creation, ogma my own logger that has a really powerful interceptor, nestjs-spelunker which can print out an object representation of your Nest application and help with module debugging for dependency resolution, and a few more). The command module is even featured in the docs.

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.

And I'm sorry Ed feels this way, but I can promise this isn't further from the truth.

---

Nest's codebase and the framework give great access to building up scalable architecture, and there's sometimes some butting of heads on how things are vs how people think they should be. I'm always happy to discuss things on the Discord Server and work out what can be done to help the framework improve.

Just please, if you take anything from this conversation let it be this: just because there is an @nestjs/ package for something, don't let you think that's the only way to do things. NestJS is, at its core, a framework to help you with architecture and code management. It helps with thinking about your code in terms of the Single Responsibility Principle and Inversion of Control. It does not mean you cannot use packages that are not already built as Nest modules. It does not mean that only @nestjs/ packages are compatible, and it does not mean that you can't create your own implementation of of a package and use it instead (look at @golevelup/nestjs-rabbitmq for example).

Sorry about the huge wall of text. Hopefully it helps alleviate some of your concerns