community icon indicating copy to clipboard operation
community copied to clipboard

Package Proposal: QUIC and HTTP3 plugin

Open iapicca opened this issue 3 years ago • 11 comments

Given that

HTTP3 QUIC are very promising, but Flutter Team has, legitimately, too much on its plate to take craft a dart package (references 1, 2, 3) and even react native approach seems to be through native clients (source)

It would be great if the community could come out with a plugin to support this feature, I don't have the brain muscles or the expertise to deal with it myself, but I'd be happy to help.

I believe there are 2 possible strategies to support QUIC :

  1. CRONET on the native side for android and ios

  2. QUICHE + dart:ffi (resource for rust + dart:ffi) could work from both android, ios, desktop and maybe in the future for web

there will be probably some js package to use for web, but I haven't located it

Do you think such plugin could be useful for the community?

iapicca avatar Oct 23 '20 18:10 iapicca

@iapicca What do you think about QUICK? I know, that the way around with golang may quite not be a good solution at all, cause of this article. But I think it is a possible solution at all, at least on native side ...

jayjah avatar Nov 17 '20 15:11 jayjah

@jayjah I'm not sure the article is still reliable (2018) anyhow I believe c/c++ and rust are an easier for dart:ffi that's the only reason why I mentioned specifically quiche but if you are able to run quick that would be awesome, I have no clue how to do that

iapicca avatar Nov 17 '20 18:11 iapicca

@iapicca I think the 2nd solution is better. Because the targets of Flutter are not only on iOS and Android but also on other platforms.

lovung avatar Dec 25 '20 02:12 lovung

for my understanding isar from excellent @leisim binds a rust base db using dart:ffi for both web and native borrowing this approach could make the second option quite realistic

  1. QUICHE + dart:ffi (resource for rust + dart:ffi) could work from both android, ios, desktop and maybe in the future for web

iapicca avatar Jan 04 '21 15:01 iapicca

@iapicca No, Isar will use the Rust engine for mobile and desktop targets and a custom typescript db engine for web. The reason is that WASM has no access to Browser APIs (IndexedDB) and has to communicate via JavaScript. Depending on the use case, this can be a lot slower than using JavaScript in the first place.

Edit: Also, Dart FFI cannot communicate with Rust on the web (WASM) so you need to use JavaScript to communicate with WASM.

simc avatar Jan 04 '21 15:01 simc

@leisim thanks for clarifying that, I guess step 1 could be mobile only for now I hope in the future there will be interoperability between dart and wasm [1, 2]

iapicca avatar Jan 04 '21 17:01 iapicca

@iapicca Unfortunately I don't think that would solve the performance problems. There are some outstanding WASM proposals that will significantly improve the situation but they will need years until all browsers ship them.

simc avatar Jan 04 '21 17:01 simc

this feature request could help help implementing the feature

iapicca avatar Jul 02 '21 21:07 iapicca

If anyone interested, cronet_flutter is the origin PoC of google/cronet.dart, and could run in Android/iOS and Windows/macOS/Linux

Sunbreak avatar Aug 20 '21 03:08 Sunbreak

i understand a native implementation might be difficult but a binding to quiche or ms-quic is not out of reach ... where are we +2 years lates ?

pomid avatar Aug 30 '23 16:08 pomid

Who is using what solutions now as an HTTP/3 server and client?

vukitoso avatar May 16 '24 08:05 vukitoso