aiothttp support pls

[HamzaYslmn]

Description

aiothttp support pls

Suggested solution

aiothttp support pls

Alternatives

aiothttp support pls

Additional context

aiothttp support pls

[o-santi]

This is actually feasible (and is probably going to happen) in the next major version. For more info, see #1251 (comment).

Ideally, the refactor should make all supabase packages pretty much http-client agnostic, so this would mean that you can use any http client of choice. I'll add more details later once I actually refactor the references of httpx away.

[HamzaYslmn]

Thank you, httpx doesn't work very well with asynchronous requests. Its ease of use is certainly great, but it can't be compared to aiohttp in terms of speed.

[pramilajangid]

I want to work on this. Is this still available ?

[HamzaYslmn]

I want to work on this. Is this still available ?

yes

[pramilajangid]

I want to work on this. Is this still available ?

yes

Before opening a PR, I wanted to confirm the expected scope.

Would you want aiohttp support to mean allowing users of the async Supabase client to pass an aiohttp.ClientSession in place of the current httpx.AsyncClient?

My initial thought was to add a small compatibility adapter at the supabase layer so existing downstream packages can keep using their current httpx-like interface without a broad refactor. Does that match what you had in mind, or are you looking for a different approach?

[o-santi]

Is this still available ?

It is not. I'm already working on it on a big rewrite for the v3 version. Do not expect this feature to be out without breaking changes.

[HamzaYslmn]

Is this still available ?

It is not. I'm already working on it on a big rewrite for the v3 version. Do not expect this feature to be out without breaking changes.

The system you designed was intended to use the client we wanted, so it’s normal for it to be in v3, but there’s not much difference between writing an HTTPX adapter and an AIOHTTP adapter. It’s ready to use.

[o-santi]

The system you designed was intended to use the client we wanted, so it’s normal for it to be in v3, but there’s not much difference between writing an HTTPX adapter and an AIOHTTP adapter. It’s ready to use.

You are correct, writing an httpx client is not far off writing an aiohttp one. However, its much different than writing a library that can be used by both httpx or aiohttp, even worse by any other sync or async http client.

For example, one problem is that we're currently tied to httpx's Headers and QueryParameters implementations. If we want to be truly http-client independent, then we need to, internally, use a type that's not from any of them - ie. we need to develop our own.

I'm already rewriting a lot of the http utilities into a separate package, called supabase_utils, that I intend to publish along with the next major version, and in there I also intend to add generic http Headers and query parameters, together with Request and Response types, which also differ by library.

In the end, I believe that all that will be needed to do is instantiate the client with a function that translates supabase_utils.http.Request (which holds both supabase_utils.http.Headers and supabase_utils.http.QueryParameters) into a supabase_utils.http.Response, and the libraries can just reference those internally. Each implementation just need to provide a way to convert from our structs into theirs, do the request, and then return the correct struct back.

It is also possible to use an off the shelf barebones implementation of those primitives if they are sufficiently general; maybe httpcore can be leveraged here? I don't know. One additional requirement is that any headers/query maps we choose, it needs to be immutable, in order to fix #1208.

Anyway, it is not trivial work, specially given I don't intend to special case aiohttp into the library, but to let anyone use any client.

[pramilajangid]

Thanks for the clarification @o-santi .
I’ll hold off on implementing this directly.
If helpful, I can assist with specific parts of the http abstraction (e.g., adapter interface or request/response structs).

[o-santi]

@HamzaYslmn While we're at it, can you provide a benchmark/use case where the difference between httpx and aiohttp is significant?

[HamzaYslmn]

httpx and aiohttp is significant?

I’m using FastAPI + Supabase on edge devices (like the Raspberry Pi). With HTTPX, there’s an concurrent limit—only around 100 requests can be processed in parallel at the same time.

However, when I wrote a custom proxy using aiohttp, I was able to send up to 1,500 requests simultaneously on the same device.

The concurrent support is much better.

Here openai example too: https://github.com/openai/openai-python?tab=readme-ov-file#with-aiohttp

[dimasd-angga]

is this issue still open? im looking for an issue that i can contribute