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

Unify sync and async clients #697

Open
tinvaan opened this issue Feb 20, 2024 · 4 comments
Open

Unify sync and async clients #697

tinvaan opened this issue Feb 20, 2024 · 4 comments

Comments

@tinvaan
Copy link
Contributor

tinvaan commented Feb 20, 2024

[This is more of a question at this point and not a feature request as such, so I'm diverging from the issue template.]

I noticed that there is a ton of shared and redundant code between the sync and async client classes. From what I'm seeing, there is only one place where a coroutine gets awaited in the async class (i.e while fetching the session token from AsyncGoTrueClient).

Does it make sense then to attempt to converge the two classes into one? if not, what are some of the challenges in doing so?

I've attempted a converge at tinvaan#2 . It's very early days still and I haven't had a chance to test the changes completely yet. But interestingly we can get rid of a lot of redundant code in this approach and as you can see in the linked PR, the code coverage jumps up significantly as a result.

However, I'd like to hear the community's thoughts on if this was attempted before or if indeed such a change makes sense.

@tinvaan
Copy link
Contributor Author

tinvaan commented Feb 20, 2024

On a related note, would it make sense to return the relevant go-true client directly in auth_client.py instead of the wrapped clients ? -- why/why not?

https://github.com/supabase-community/supabase-py/blob/main/supabase/_sync/auth_client.py#L12

/cc @J0 , @olirice , @silentworks

@silentworks
Copy link
Contributor

There are no manual duplication being done in the codebase as we have a make command we run to create the sync code. We have these separate because not all Python framework's support async and I think the libraries were originally written as a sync library. We are always open to ways of improving the codebase and will take a look at your PR.

@tinvaan
Copy link
Contributor Author

tinvaan commented Feb 24, 2024

Thanks @silentworks. Yeah, in that case I don't see any reason to check in the generated _sync folder in to version control. The _sync folder can be generated on the fly during the release as it is practically just a build artifact.

That said, I'd feel more confident in releasing code that we actively maintain and track in version control and has sufficient test coverage. Hence, making this unification attempt.

Please correct me if I'm wrong^

@tinvaan
Copy link
Contributor Author

tinvaan commented Mar 11, 2024

Just a heads up that there is a WIP changeset over at tinvaan#2

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

2 participants