Experience gained when working with WebAssembly+Rust outside the browser, in the MuleSoft Flex Gateway implementation

1. All contents © MuleSoft, LLC
Rust usage and adoption
in Flex Gateway
WASM beyond the browser

2. All contents © MuleSoft, LLC
Andres Testi Jorge Perez Leonardo Centurion
We are
LMTS @ Mulesoft AMTS @ Mulesoft
leocenturion
LMTS @ Mulesoft
andrestesti
jolisper

3. All contents © MuleSoft, LLC
What is Flex Gateway?
Flex Gateway is a lightway and cloud-friendly API Gateway, designed to manage
and secure APIs in standalone, integrate seamlessly with DevOps and CI/CD
workflows, or managed mode, via Anypoint control plane.

4. All contents © MuleSoft, LLC
What is Flex Gateway?
Technically speaking, we're not building an API gateway from scratch. We are
building an API Gateway controller that adapt configuration (either from files, APIs
or Anypoint Platform) to a particular gateway implementation: Envoy.

5. All contents © MuleSoft, LLC
Flex Gateway Overview
Anypoint
Policy
Engine
Envoy
Anypoint
Connector
Config
Language
Internal
Metrics
Ext

6. All contents © MuleSoft, LLC
Why Envoy?
● Adoption
● Simple Programmability Model
● Performance
● Portability

7. All contents © MuleSoft, LLC
Why Envoy?
● Extensibility
● Sandboxing

8. All contents © MuleSoft, LLC
How WASM fits in Reverse Proxies?
● Developed by major corporations (W3C, Mozilla, Microsoft, Google, Apple).
● Widely deployed.
● Portability.
● Many available programming languages (Rust, C/C++, TinyGo,
AssemblyScript).
● Safe extensibility due to sandboxing.
● Single-threaded by default.
● Plugin-oriented
● Binary format

9. All contents © MuleSoft, LLC
How Rust is bound to WASM? (FFI)?
● FFI extern functions are provide to call the host
● Rust must provide extern functions to be called by the host
● Proxy-wasm SDK provides a basic implementation of this interaction

10. All contents © MuleSoft, LLC
What is proxy-wasm?
● A standard platform for reverse proxies
● It includes an event oriented ABI

11. All contents © MuleSoft, LLC
WASM downsides?
● No garbage collector yet (Not an issue for Rust)
● Expensive host interaction, data must be serialized/deserialized into buffers
● Not all functionality is available (proxy-wasm is very limited, random
generators are broken)
● While there is an ad-hoc allocator (wee-alloc) for the linear memory, it is
limited due to restrictions of single threading and contiguous memory. It’s
suboptimal for intensive use.

12. All contents © MuleSoft, LLC
How is proxy-wasm related to WASI?
● Proxy-wasm predates WASI
● It was the first standardized ABI in WASM
● While there is some overlapping (e.g clock management), they are generally
complementary.
● WASI is a kind of POSIX standard, while proxy-wasm is focused on proxies.
● They can be used together in Envoy, since it supports a subset of WASI ABI.

13. All contents © MuleSoft, LLC
Pluggable Architecture

14. All contents © MuleSoft, LLC
Envoy supported WASM runtimes
● V8
● WASM Micro Runtime (by Byte Code Alliance)
● Wasmtime
● WAVM

15. All contents © MuleSoft, LLC
Why Event Loops?
● Single Threading.
● Scalability.
● Concurrency.
● Race conditions free.

16. All contents © MuleSoft, LLC
Life of a request
Backend
Filter
on_request_headers
Request to backend
on_request_body
Response from backend
on_response_headers
on_response_body

17. All contents © MuleSoft, LLC
Listener
subsystem
(Dispatcher)
Filter
proxy_on_http_request_headers
proxy_get_map

18. All contents © MuleSoft, LLC
proxy-wasm ABI
● The ABI defines a set of function headers for Host/Module interaction
● There are two kinds of functions:
○ Functions implemented by the Host
○ Functions implemented by the module
● Functions implemented by the Host are usually providers of information:
○ proxy_get_current_time()
○ proxy_log()
● Functions implemented by the module are usually used as event listeners
○ proxy_on_http_request_headers()
○ proxy_on_http_response_headers()
○ proxy_on_memory_allocate()

19. All contents © MuleSoft, LLC
Rust / proxy-wasm bootstrapping?
● Envoy calls the _start() function
● proxy_on_vm_start() is called when the virtual machine is started
● proxy_on_configure() is called when the config is updated
● proxy_on_context_created() is called when a new request is incoming
● Events are invoked in order (request headers, body, response headers, etc)
● proxy_on_done() is called when the request ends

20. All contents © MuleSoft, LLC
Communication with the host

21. All contents © MuleSoft, LLC
What proxy-wasm-sdk provides?
● extern “C” function headers
● A Dispatcher system for calling events
● A set of traits with default impls to define the event handlers
● Data serialization and deserialization between Host/Module boundaries
● RootContext, HtmlContext (L7) and StreamContext (L4) support

22. All contents © MuleSoft, LLC
Getting all headers

23. All contents © MuleSoft, LLC
Communication with the plugin
So the compiler won’t
change the name of the
function.
The host is expecting that
name

24. All contents © MuleSoft, LLC
The host calls
the plugin in the
root context
When an http request comes
another struct is used in a worker
thread
The previously created struct
handles the events that
correspond to that request and
the subsequent response

25. All contents © MuleSoft, LLC
Conclusion
● proxy-wasm is a safe, portable and performant extension mechanism.
● proxy-wasm and WASM itself are still in early stages.
● Programming model is still hard.
● Functionality is very restricted.
● Rust seems to be the best fit for WASM.
● The future is promising.

26. All contents © MuleSoft, LLC
Q&A
Q&A

27. All contents © MuleSoft, LLC
References
● Flex Gateway: https://www.mulesoft.com/platform/api/flex-api-gateway
● WASM: https://webassembly.org
● WASI: https://github.com/WebAssembly/WASI
● Proxy WASM: https://github.com/proxy-wasm/proxy-wasm-rust-sdk
● Envoy: https://www.envoyproxy.io

28. All contents © MuleSoft, LLC
Thank you