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