Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialization of global clients #31

Open
Moleandr opened this issue Aug 6, 2023 · 3 comments
Open

Initialization of global clients #31

Moleandr opened this issue Aug 6, 2023 · 3 comments

Comments

@Moleandr
Copy link

Moleandr commented Aug 6, 2023

@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?

@duarte-pompeu
Copy link

I've faced a similar situation where we needed to authenticate to those clients via OAuth. Here's what we did:

  • use a scheduler (APScheduler) to regularly authenticate and get new tokens, stored globally
  • each integration had its class, a sort of SDK, wrapping the calls with extra validation/logic/logging
  • use dependency injection / factory pattern to create new client objects on each request, injected with the global token

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.

@zhanymkanov
Copy link
Owner

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:

  1. Create a global client
  2. Init the client on the app start
  3. Access the client within the app.

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.

@zhanymkanov
Copy link
Owner

zhanymkanov commented Aug 10, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants