Read on Twitter
The dependency injection hate is strong on hacker news https://news.ycombinator.com/item?id=25047409 #dotnet
My hot take is this: I do believe that having to deal with DI makes things more difficult to learn initially. It *is* a barrier to entry and in some cases, people get trigger happy and overuse the DI container (everything becomes a service).
Having said that, I've written code both ways and that ceremony can pay off in huge ways as a project matures and changes are made. There's a tipping point though where it feels like additional complexity until it has paid off.
More than that there are fundamental problems that it solves when you introduce frameworks that call you back (Hollywood principle Don’t Call Us, We’ll Call You). We need to able to instantiate user code or callback user code on a per request basis.
We're also not single threaded so creating state and using it in a callback makes that object a singleton and it needs to be thread safe. Writing efficient thread safe code is hard. This works fine in nodejs because it's single threaded.
Closing over state declared at top level in your per request closure is "fine".
I think if unit testing isn't a valuable thing to do in these cases, then feel free to litter code with statics and hard code reading environment variables. If you ever need to change that then we can have that discussion on how you can refactor the code to use abstractions
