OpenAPI client generator factory mode

[Leon0824]

Is your feature request related to a problem? Please describe.

My use case is one OpenAPI spec with multiple parties. Currently, the generated OpenAPI client is a global instance inside client.py. In my case, the global instance is configured a base URL of party A. Because the client is global, it is not unable to configure the base URL to party B, or requests to A would be sent to B, race condition happens.

More specifically, I am working on OCPI. Its an industry protocol for EV roaming charging. There are multiple charging companies with the same OCPI standardized API endpoints and the same request parameters interactive each other.

Describe the solution you'd like

OpenAPI client generator factory mode. The client.py have a client factory. We initialize a client for a specific party from the factory class (or function).

[mjeammet]

Hi ! Same problem here, we're handling several identities and it's going to create a race condition in async mode.
Curious about any workaround or solution.

[phalt]

I'm gonna dig into this over the next few weeks and see what I can do. If you can provide more examples - code examples or workflows to help me understand the problem more that would help me a lot.

[mttbernardini]

An idiomatic approach to solve this problem could be to use contextvars and a context manager user-facing API. Adapting from the linked commit from @phalt:

from clientele import api as clientele_api

client = clientele_api.APIClient(base_url="https://default.example.com")

@client.get("/users/{user_id}")
def get_user(result: User, user_id: int) -> User:
    return result

# One config per party / tenant
party_a = clientele_api.BaseConfig(
    base_url="https://party-a.example.com",
    headers={"Authorization": "Bearer <token-for-a>"},
)
party_b = clientele_api.BaseConfig(
    base_url="https://party-b.example.com",
    headers={"Authorization": "Bearer <token-for-b>"},
)

with party_a:
    user_from_a = get_user(user_id=1)

with party_b:
    user_from_b = get_user(user_id=1)

Benefits of using a contextvars-based approach:

• thread/task-safe by design
• automatic "injection" across the call-stack (similarly to how cancellation scopes work in anyio).
• less "pollution" on generated functions with parameters that are not related to the function itself

Thoughts?