Any plans to implement QUIC protocol?

[tysonrm]

No description provided.

[juntao]

Not yet. Do you have to try it? :) The general approach is to add QUIC's native shared library as host functions in the WasmEdge/WasmEdge repo, and then create a Rust API for those functions here.

[tysonrm]

I have a JS microservice framework that implements deployment and language independence without the need for distribution and obviates the need for deployment automation (i call the components "federated microservices" or "microservice libraries") . The complexity of distributed systems is the main reason microservice projects fail and why many orgs choose not to implement.

It is based on module federation, hexagonal architecture and wasm. I view this tech as transformative. It "just works" and solves many problems and leads to more oppty. For example, I didn't set out to create what is essentially a serverless platform with no vendor lock-in and no deployment tooling required.

Anyway, the framework will operate like a self-forming, uniform substrate or fabric that transparently integrates and dynamically deploys and runtime binds components. Support for fast streaming and manipulation of streams (e.g. AI interference) is critical. I am comfortable with async I/O capabilities of Node but need the speed and non-blocking behavior of QUIC. Any provider can plug into the service mesh, which runs in process with the federation host (not as a sidecar). Support for QUIC has been dark launced in Node 16 (requires recompilation with expiremental flag). So exploring possibilities. Thanks, Michael. Love your work!

[tysonrm]

I'll leave this open for now, if that's okay, to track development of a Rust API for Node's Quic implementation, which I plan to develop in the near future.

[juntao]

Yes, I think WasmEdge can be embedded into your JS framework as a runtime for 3rd party plug-ins. Networking can be done in the JS host or in WasmEdge.