Open DanielWilkowski-HammerPay opened 1 year ago
Hi @DanielWilkowski-HammerPay , This is an interesting idea and something we've been considering supporting within the library. Would you want to configure the underlying HTTP library that's being used today or swap that out entirely for something different. If it's the former, could there be options that we could expose when instantiating the library?
Hi @DanielWilkowski-HammerPay , This is an interesting idea and something we've been considering supporting within the library. Would you want to configure the underlying HTTP library that's being used today or swap that out entirely for something different. If it's the former, could there be options that we could expose when instantiating the library?
I can't speak for others, but me myself have 3 reasons to do this:
Currently, the http client of Dwolla client is hermetic, and there is no way to access and/or extend it from the perspective of the users.
However we, for the purpose of development, would like to supply our custom http client implementation for the usage in dwolla sdk, for example to debug, log and intercept requests.
Currently, that's not possible because the interface of dwolla api is
DwollaClient.create(isSandbox: true)
and the constructor ofDwollaClient
isinternal
.Do you think it would be possible to:
DwollaClient
constructor aspublic