-
-
Notifications
You must be signed in to change notification settings - Fork 94
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
Architecture Discussion For v6 #39
Comments
Hi Grant, Can you give some C# code examples of the token expiration flow and how you handle renewal? I'd like to see these pain points first hand and then I'll be able to comment further on the issue. Let me know. Thanks, |
I’ll have a pull request for you soon
…On Mon, Nov 12, 2018 at 10:04 PM Brian Chavez ***@***.***> wrote:
Hi Grant,
Can you give some C# code examples of the token expiration flow and how
you'd handle renewal?
I'd like to see these pain points are first hand and then I'll be able to
comment further on the issue.
Let me know.
Thanks,
Brian
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMsMnewYY-uCVcc9NGE-Hz82kDsMoP-Bks5uujbagaJpZM4YYKTe>
.
|
I've created a branch for Normalization for future version, it's mostly done, but I'm not satisifed with it currently, its not as fluent as it should be https://github.com/granthoff1107/Coinbase/tree/NormalizationV7 I'll open a seperate issue for OAuth and Well discuss it there I think its do able with the current api |
I was trying to integrate refresh tokens when I came across some issues.
The Architecture changes I'm going to propose should probably be for the next version v6 and not for now. I'm a bit confused on why the coinbase is inheriting from the FlurlClient.
This is creating a hard dependency on the FlurlClient. The client is subject to be changed (e.g) the last version was using RestSharp Client Perhaps their should be a protected property instead for the client, to abstract the depedency.
The current architecture makes it difficult to modify the request control flow, if someone wanted to catch an error such as expired_token, currently they would have to wrap every request made.
If the endpoints were made properties, and all inherited from the same base interface/ class, a builder could be used to construct the request, and the base class could have an execute function (similar to the prior version) which could be overridden to make it easier to change the control of each request.
For now I'm going to integrate the beta with my api.
lets discuss this more when you get a chance
The text was updated successfully, but these errors were encountered: