refactor: share one Session across the client tree via composition (#2, #3)#137
Merged
Merged
Conversation
Resources subclassed API, so each opened its own requests.Session; a Datamaxi client spun up ~15 pools and every grouping class (Cex, ...) was itself an API it never used as one. Add an API-composing Resource base (has-a, not is-a) that holds a shared API and forwards request_endpoint/query. Datamaxi now builds ONE API and threads it through the whole tree via api=, so all sub-clients reuse a single Session / connection pool. Resource method bodies are unchanged (api rides through **kwargs); standalone instantiation still builds its own transport. No public surface change: client.cex.candle(...) etc. work as before.
This was referenced Jul 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR 3 of 4 from the SDK-structure review — fixes issues #2 (per-resource
Sessions) and #3 (is-a instead of has-a) together, since they share one root cause.Before: every resource subclassed
API, so eachsuper().__init__opened its ownrequests.Session. A singleDatamaxiclient created ~15 sessions/connection pools; grouping classes likeCexwere anAPI(inheritingsend_request,_handle_exception,session, …) they never used as one.After: a new
Resourcebase (inapi.py) composes anAPI— holds a shared instance and forwardsrequest_endpoint/query.Datamaxibuilds oneAPIand threads it through the whole tree viaapi=; the value rides through**kwargs, so resource method bodies are untouched. Standalone instantiation (CexTicker(api_key=..., base_url=...)) still builds its own transport.Net: one
Session/ connection pool for the entire client, andclient.cexis now a namespace (Resource), not anAPI.Verification
Datamaxi("k"): 1 distinct_apiobject and 1 distinctSessionacrosscex,cex.candle,cex.ticker,cex.symbol,premium,funding_rate,liquidation,index_price;isinstance(cex, Resource)True,isinstance(cex, API)False; standaloneCexTickerkeeps its own transport.pytest -m "not integration": 134 passed, 11 skippeddatamaxi/Compatibility
No public surface change —
client.cex.candle(...), direct resource instantiation, and the mocked/live test lanes all behave as before. conftest'sAPI.send_requestmonkeypatch still applies (delegation routes through the sharedAPI)._endpoints.py(codegen'd upstream) untouched.Known failures
None.
Note
The
Resourcemethods forward onlyrequest_endpoint/query— the twoAPImembers any resource actually calls onself(verified by grep; no resource touchesself.session/self.base_url/send_requestdirectly).