You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make functions _async.client.create_client and _async.client.AsyncClient.create synchronous.
Problem description
Right now, acreate_client is a re-import of the _async.client.create_client function. This function has been marked as async (see source code). This function, in its body, calls the AsyncClient.create asynchronous class method (see source code). This method itself calls AsyncClient.__init__, which, however, is not asynchronous (see source code). This approach has a negative impact on the user experience for several reasons.
First, this chain of function calls, passing the same arguments with the same names three times until it reaches the destination constructor, seems to introduce a lot of unnecessary abstractions.
The second reason is that most Python applications would instantiate Supabase clients either in synchronous mode (for example, during the creation of an ASGI application in the main loop) or asynchronous mode (when creating multiple clients in asynchronous functions). Both of these approaches can use the synchronous create_client function. However, the first approach cannot use the asynchronous create_client, as this code would be executed in the main loop, not in an asynchronous environment, and therefore a single asynchronous client could not be created in main loop and shared among asynchronous workers.
Proposed Solution
I propose remove async mark from both create_client and AsyncClient.create functions, make create_client call AsyncClient.__init__ directly, and probably, rename re-import from ._async.client import create_client as acreate_client to create_aclient since this naming better represent what function actually does. (not asynchronously create client but create asynchronous client)
I agree with you about return await AsyncClient.create(, this is remnant of old code that was not removed at the time of some changes that were made to the library. Changing the name now from acreate_client to create_aclient would be a breaking change and doesn't have much benefit to it other than personal naming convention. You can open a PR with the change to
Feature request
Make functions
_async.client.create_client
and_async.client.AsyncClient.create
synchronous.Problem description
Right now,
acreate_client
is a re-import of the_async.client.create_client
function. This function has been marked asasync
(see source code). This function, in its body, calls theAsyncClient.create
asynchronous class method (see source code). This method itself callsAsyncClient.__init__
, which, however, is not asynchronous (see source code). This approach has a negative impact on the user experience for several reasons.First, this chain of function calls, passing the same arguments with the same names three times until it reaches the destination constructor, seems to introduce a lot of unnecessary abstractions.
The second reason is that most Python applications would instantiate Supabase clients either in synchronous mode (for example, during the creation of an ASGI application in the main loop) or asynchronous mode (when creating multiple clients in asynchronous functions). Both of these approaches can use the synchronous
create_client
function. However, the first approach cannot use the asynchronouscreate_client
, as this code would be executed in the main loop, not in an asynchronous environment, and therefore a single asynchronous client could not be created in main loop and shared among asynchronous workers.Proposed Solution
I propose remove
async
mark from both create_client and AsyncClient.create functions, makecreate_client
callAsyncClient.__init__
directly, and probably, rename re-importfrom ._async.client import create_client as acreate_client
tocreate_aclient
since this naming better represent what function actually does. (notasynchronously create client
butcreate asynchronous client
)I believe this solution would be beneficial because
acreate_client
could be used in both contexts:If you have any other opinions or know of any nuances that I have not taken into account, please share them in the discussion. Thank you!
The text was updated successfully, but these errors were encountered: