Deployment modes
There are different ways to deploy applications on Wasmer Edge:
- TCP/UDP applications
- WebServer applications
TCP/UDP applications
TCP and UDP applications are also supported in Wasmer Edge, but we haven't exposed the API as is still in alpha phase.
If you want to run TCP or UDP applications (such as video server, a websockets application or more) please let us know on this issue (opens in a new tab), or ping us in Wasmer Discord (opens in a new tab).
WebServers
WebServers are the most common type of applications.
Wasmer Edge support two modes for webservers: Proxy and WCGI, and each comes with it's own advantages and tradeoffs.
Proxy
In proxy mode, the WebAssembly instance is expected to start an HTTP server on
a specified port (currently defaulting to 80).
The Edge gateway will then forward (proxy) requests to the inner server, and send the response back to the client.
A started application will be re-used for multiple requests, and even concurrently if the application runs a multi-threaded server. This increases performance, thanks to reduced startup overhead and lack of a required warmup.
This deployment mode currently requires the WASIX (opens in a new tab) WebAssembly toolchain, a superset over WASI (opens in a new tab). WASIX adds additional functionality to WASI, in particular the ability to listen on sockets.
To learn how to Deploy a WASIX server, follow the Rust HTTP Server Quickstart.
To learn more about WASIX and how to build WASIX-enabled applications, see the wasix.org (opens in a new tab) website, or the WASIX announcement post (opens in a new tab).
WCGI
WCGI, short for WebassmblyCommonGatewayInterface, uses the tried and true CGI (opens in a new tab) protocol to process HTTP requests.
For each incoming request, the gateway will start a brand-new WebAssembly instance,
provide request information through env vars and stdin, and then read the
response from stdout.
This means you can use every language and toolchain that compiles to WASI by simply using a library for CGI, which is available in pretty much every language.
The primary benefits of this approach:
- Supported by all languages that already compile to standard WASI
- Isolation: Each request is handled in a isolated context in a new application instance, which is sandboxed. This means there is no way for requests to negatively affect each other by blocking threads, or for bugs or vulnerabilities introduced by shared state.
- Perfect scalability: The gateway starts a new instance for each request, so there is no need to worry about concurrency or thread safety. The Edge gateway will do the work for you, and scale up dynamically. Your instances also stop immediately after the request is served, so you don't incur any additional cost from idle instances.
To run WCGI workloads locally, see the WCGI Runner docs.
You can also check out the WCGI announcement post (opens in a new tab).