So I want to inject an Application Client, say a Rest Api client, in my code. In order to create this client I need to go over the network to get it's user and password that is in a HTTP Vault.
This behavior got my team divided, some saying it's an anti-pattern to go to the network before finishing injection, some others saying this is fine.
What could be the problems going through the network during DI phase?
"during DI" is the sticking point here. I can point you to numerous references1,2,3 that argue that constructors should not do "real work" (and others4,5 that argue that it's fine). That is, they should stick to validation and initializing state. But "during DI" can be taken to mean more than simply stuff constructors do. It's also the work done to call those constructors.
I know of no advice prohibiting network communication prior to calling constructors. Just understand, much like file IO, this will be slow.
Doing this work prior to construction means your dependent object will be ready to go whenever it exists. Thus you never have to ask it if it is. And you can be fairly confident that it's construction will succeed.
You can ignore all that I'm sure. Just keep in mind anything that the constructor does or calls is being shoved down the class users / testers throat. Be sure you mean to do that before you do that.
But it's not the same issue just because you're doing it "during DI". Unless you have some flaky DI framework that makes doing this work outside of your constructors a pain.
Wether and/or when you access the network or whether this is done in a constructor or not seems utterly irrelevant to me. What matters is that if you pass in an uninitialized object (not logged on yet), the receiver would have to know and do a lot before it can actually use the injected interface. This pretty much defeats the purpose of DI.
So the better way to go would be to prepare the client object and then inject an interface to it that provides just the functionalilty needed.
The main problem I would have with doing network calls while setting up a DI (I'm assuming a framework is being used) is that it can fail.
What would then happen. Is the DI framework then uninitialized and no dependencies can be used? Would just the network client broken and not able to be used? Do you keep retrying the network request and block the whole app.
The other problem is performance. Since this could be slow, it delays when all the other dependencies can be used.
I would instead recommend creating some sort of wrapper around the http client that knows how to retrieve the credentials or just a credential requester. Then the credentials should be retrieved lazily with appropriate retry logic. If unable to get the credentials the request fails and is handled like any other failure.
As others pointed out the network might be down or it might be slow. What you are trying to implement is the classic publish/subscribe mechanism, buy by putting it directly into the constructor phase of your application you are turning it into a tight coupling. Many problems may arise, you might end up writing an application that crashes on startup if the network is not there without logging the problem or, you might have an application that hangs unexpectedly if the client has a problem and the system administrator would not be able to understand that the problem is in the client.
