[wouldbecouldbe]

NestJS is nodeJS for Java people. It's like Angular in that sense.

So some people will feel like it's over engineered.

I mean it's overengineered. Why do I have to register all these things, and why does it keep crashing if I register it like this without any understandable error message. It has a little bit of an OCD relationship with dependency injection. Where the normal import system can handle most of those cases.

But few nice things, resolvers, auto-generate swaggers. And TypeORM is lovely.

But yeah it's a bit too demanding. I'm okay with an opiniated framework if it gives a lot of features out of the box (like laravel or NextJs), but NestJS tells me how to do things without giving me enough in return. (auth, sockets etc are still quite a lot of work)

[mewpmewp2]

Yeah, I don't know, most of the time only time you actually need dep injection is for tests, and at that point why not just mock with Jest? Feels too much just having to do all this work just to complicate dependencies and make moving around more difficult for tests when a much simpler solution is available.

[tisdadd]

Just wanted to chime in and say that if you use the CLI to generate things, the experience is much nicer. However, you do still need to be in their playground. If you have a large team out org and don't want to have to document extra about the guts, I love having something proven. If you need to mix protocols, I believe Feathers JS was a little simpler to get into last I looked.

[wouldbecouldbe]

Defacto standard is express with mature packages, that will get you a lot more then nestjs or featherjs and a lot simpler.

[wouldbecouldbe]

Dependency injection was not really meant to help with testing, but to keep code decoupled. It can be a nice pattern, but even if nestjs forces us to do it, we developers still find creative ways to nullify any attempts to decouple the code we write :).

[mewpmewp2]

It wasn't meant to, but it realistically and potentially feels only useful in those cases.

To me in most cases it is used it seems to just overengineer and obfuscate things unnecessarily when much simpler code would be easier to understand, etc.

It shouldn't be a thing that is done by default, only when it really makes sense.

Eventually with all those injections you are going to cause a situation where making any changes becomes really complex, if there are any use cases you didn't foresee at all.

In 90%+ cases you don't need interfaces and or DI, you should just be able to follow the logic with your IDE, it makes no sense to obfuscate that.

If the impl truly must vary for whatever case, then sure, you can use it.

But I would also say that don't do interfaces and impl before you actually need to switch them out dynamically depending on the context (and not just for testing).

If you have something that does Storage, and Storage drivers could be different like FileSystem, GoogleDrive, whatever, then sure use an interface, but not otherwise.

It's like DRY. Unless you actually use it 2-3 times, don't make everything unnecessarily into a reusable fn.

If you don't foresee having multiple storage methods in the near future then just use a class for storing which you can move to, to see how it does file storage or similar.

[wouldbecouldbe]

yeah agree, there was a time where everyone only wanted to code in patterns. I do think they are nice, but often most of us hardly understood the original reason why they were created.