Feature request: refactor to use Dio?

[frmatthew]

Is your feature request related to a problem? Please describe.

The use of the default http package is a common selection for basic http operations in many Dart/Flutter projects. However, the http package fails to provide a comprehensive suite of network operations that could enable the implementation of more advanced features for superbase_flutter and related packages. For example, there are several important features for storage-dart that are practically infeasible to implement with http (progress callbacks for upload/download, file transfer pausing/resumption, and others).

On the other hand, the Dio HTTP package is a well tested and popular alternative to the http package, that provides the necessary APIs to implement the above features. For example, out of the box, Dio supports upload/download progress callbacks on the client side; Dio has extensions for retry and has http interceptors that I believe can be used eventually for file transfer pausing/resumption.

Describe the solution you'd like

My thought is that by migrating the supabase_flutter and related packages to utilize Dio for http connections and operations, implementing these client side operations will be much easier and cleaner.

Describe alternatives you've considered

I have explored implementing upload/download progress callbacks using the existing architecture; it is possible to use streams to track download progress, but tracking upload progress is not possible, since the existing Clients utilized in the storage-dart package don't expose the byte streams for requests.

Additional context

• I am relatively new to the supabase_flutter architecture, so it's possible there are concerns that would preclude switch the packages to Dio.
• I also realize that this would not be minor change, as it impacts much of the core code. But perhaps switching sooner rather than later would prove to be beneficial in the long run.
• I would be happy to begin assisting in the migration. I could first migrate the storage-dart library to evaluate the impact and challenge of such a change.
• I didn't see any discussion of this proposal anywhere else, but my apologies if it's already been evaluated and considered.

[dshukertjr]

Thanks for the suggestion, but we will not migrate away to a third party package from the officially maintained one. Upload progress is coming to storage using the TUS protocol soon.

[frmatthew]

Thank you, that's understandable. Will integration of TUS bring with it download progress callbacks as well? Anywhere I can tracks the status of these features? I see a few issues related to this request (#308, #76 , stoage-api #23), but they're either old or closed it looks like.

Thanks again.

[Vinzent03]

@frmatthew For download I don't think, because that's not part of TUS afaik. We are waiting for storage-js to implement that feature first and then port it to Dart. I've already created #438

[frmatthew]

What about something like this for download progress? It's a simple solution that remains backwards compatible by just using optional parameters, and it also is flexible enough to use for upload progress when that arrives (I think).

I'd be happy to turn this into a PR, but I wasn't sure if this was already underway. I did see this, but I think the above is a little cleaner.

[Vinzent03]

Have you tested if it works? Because from this comment it seems like it didn't work for upload.

[frmatthew]

It works for download progress yes, though I can certainly beef it up; but it doesn't implement upload progress callbacks yet. To track upload progress would require either TUS integration or a reworking of how the http client is managed throughout the supabase packages. Since TUS integration is upcoming, it's premature to work on upload progress, but since we'll need download progress too, I'm proposing putting together a PR with something like the above branch if it would be considered for merging.

I'm really just trying to see if I can help make progress on this front: I see requests for download/upload progress date back to 2021, and it's a pretty important feature for us, so even if I can get download progress, that would be a great help for us. But if you have other plans or ideas in mind to implement download progress, I'll figure out something else for us in the meantime.

[frmatthew]

I determined a simple way to also include upload progress callbacks, so I took the liberty of preparing the above PR for consideration & any further discussion.