Having started to look into it a couple of times, it seems that the intersection of the Nest DI system and the fact that annotations are still mostly broken in TS/JS creates an extremely twisted usage/API surface.
I’m not even sure why all of these shenanigans are necessary. I never had to use DI in Django or in Go and both of those are very capable web development environments.
A good DI engine makes for a really nice dev experience.
I grew up in the “just pass dependencies in the constructor, you don’t need a DI framework” camp. Finally tried Spring Boot recently and really like how easy it is to summon an instance of a dependency where you need it. The difference between the two mainly comes down to whether you prefer to program or metaprogram (there’s no wrong answer there). Per usual, the metaprogramming approach ends up being more terse but also sharper. You have to be careful that there actually is a component of the requested shape available when you ask for it, or you get awful errors at runtime.
On the JVM, it’s pretty common. I’ve been using Quarkus with Kotlin lately for MVPs, and I really like the use of it there. It uses a standard set of annotations so you’re not as locked in to Quarkus itself.
I’ve also tried NestJS when I was playing with JS/TS, and it seemed okay.
I’m sure there are other places it is used, I just tend not to branch out unless I feel I really don’t like what my current one offers. I suspect DI usage is higher in strongly-typed cultures (minus the FP contingent).
If I had a time machine, I would go back and tell the team to use Django, Postgres, and REST. However, I joined a 3+ year old company that made other choices.
Typing is less an issue here than poor documentation. The property simply isn’t documented. The interaction between caching and dynamic modules is not well-documented.
Dependency injection isn’t needed, but it certainly makes some aspects of development easier to reason about, and allows for improved decoupling of modules. Unfortunately, we are limited to injecting class implementations, instead of interfaces, so the TypeScript implementation of DI is a bit less robust than what I’ve used in Java.
Having started to look into it a couple of times, it seems that the intersection of the Nest DI system and the fact that annotations are still mostly broken in TS/JS creates an extremely twisted usage/API surface.
I’m not even sure why all of these shenanigans are necessary. I never had to use DI in Django or in Go and both of those are very capable web development environments.
A good DI engine makes for a really nice dev experience.
I grew up in the “just pass dependencies in the constructor, you don’t need a DI framework” camp. Finally tried Spring Boot recently and really like how easy it is to summon an instance of a dependency where you need it. The difference between the two mainly comes down to whether you prefer to program or metaprogram (there’s no wrong answer there). Per usual, the metaprogramming approach ends up being more terse but also sharper. You have to be careful that there actually is a component of the requested shape available when you ask for it, or you get awful errors at runtime.
I understand this but where do I find one other than in Spring Boot?
(I refuse to use PHP so please no Symphony.)
On the JVM, it’s pretty common. I’ve been using Quarkus with Kotlin lately for MVPs, and I really like the use of it there. It uses a standard set of annotations so you’re not as locked in to Quarkus itself.
I’ve also tried NestJS when I was playing with JS/TS, and it seemed okay.
I’m sure there are other places it is used, I just tend not to branch out unless I feel I really don’t like what my current one offers. I suspect DI usage is higher in strongly-typed cultures (minus the FP contingent).
If I had a time machine, I would go back and tell the team to use Django, Postgres, and REST. However, I joined a 3+ year old company that made other choices.
Typing is less an issue here than poor documentation. The property simply isn’t documented. The interaction between caching and dynamic modules is not well-documented.
Dependency injection isn’t needed, but it certainly makes some aspects of development easier to reason about, and allows for improved decoupling of modules. Unfortunately, we are limited to injecting class implementations, instead of interfaces, so the TypeScript implementation of DI is a bit less robust than what I’ve used in Java.