Open Moleandr opened 1 year ago
I've faced a similar situation where we needed to authenticate to those clients via OAuth. Here's what we did:
I was quite happy with the results: readable, testable, working code.
What we didn't test was the performance: this was a tiny app used by a small number of clients.
That's a good question!
Well, it depends on how those clients should be initialized (e.g. per process or per request), but I don't believe there are a lot of strategies for that. The one we used was to:
You can check examples here with redis and here with postgres that are initialized on the app start. I understand that you have a lot of apps to be initted and it can be messy to keep them all, but if they are loosely coupled, then this is one of the more popular ways to handle global clients.
If some of the clients are kin to each other, then we encapsulate them within a common providers storage class.
I think the @duarte-pompeu solution is decent and neat, if you are not worried about the reuse of http connections. Otherwise, keeping the context of the client only within the request might be not performant vs per process.
If the load is not that high and requests to the external provider have longer gaps in usage, then per request context is totally fine and maybe better, i.e. if you have 20 providers, but you call each one of them once per hour then it makes no sense to create a persistent client.
@zhanymkanov thanks for the write up. This article is very useful for me!
In our work, we often deal with a large number of integrations with third-party systems, for this we need to create global clients, what is the most correct way to do this in your opinion?