Picture this: You're building the next generation of microservices architecture in your organization. The orchestration is in place, containers are humming, and you've chosen Kong Gateway (naturally) to manage the APIs, ensuring smooth communication.
But then, you hit a snag.
You need a custom filter not part of the standard library of plugins, or you envision a unique way to manipulate, observe, or control the traffic. Traditional non-Lua PDKs can be cumbersome (because of their out-of-the-process nature), require intimate knowledge of the Kong request lifecycle, etc.
Enter WebAssembly and Proxy-Wasm. What if you could develop custom filters with the power, flexibility, and portability that WebAssembly offers and seamlessly integrate filters developed for Envoy in Kong Gateway?
In this post, we'll dive into WebAssembly, and how it's revolutionizing the way we think about and implement custom filters, offering a horizon of possibilities that once seemed like a distant dream.
[Proxy-Wasm](https://github.com/proxy-wasm/spec)Proxy-Wasm is an open-source specification that allows engineers to create filters, similar to custom plugins in Kong, using a language they're comfortable with. These filters can then run on any proxy that supports the Proxy-Wasm standard, such as Kong Gateway, Envoy, and potentially Kuma in the future.
Imagine being able to write a filter in Go, which (we hope) you're familiar with, and have it work on both Kong Gateway and Kuma simultaneously. That’s pretty neat!
Let's start from the beginning and explore what Proxy-Wasm is, why it's useful, and how it works.
WebAssembly is relatively new, it was announced in 2015 but not released until 2017.
The name, WebAssembly, is intended to suggest that assembly-like language can be executed by web browsers on the user’s computer (i.e. client-side). The original intent was to provide near-native code execution speed for web browsers, but as we’ll discuss, the use cases have expanded beyond this. It was designed for high-performance computationally intensive tasks, such as games, multimedia applications, and simulations.
**The developer experience** in the context of web development is first to write some functionality in a high-level programming language that you are familiar with (Rust and Go are popular), and then using a WebAssembly-compatible compiler, compile the source code to a wasm module (these are those .wasm files). The output is a wasm module, low-level bytecode, that can now be run in a Wasm runtime.
Well, wasm code runs in a sandboxed environment to ensure security. It has limited access to system resources and can't perform arbitrary operations without going through the defined APIs. There are several runtimes available today: Wasmtime, Wasmer and V8 as some examples.
Assuming you want to use this from the context of web browsers, the wasm modules can be loaded and executed within the web browser using a combination of Javascript and browser-specific runtime engines that provide Wasm support. Today, all major browsers support Wasm.
This is all great. What does this have to do with you, an engineer, using gateways every day to produce new business functionality?
There is a fundamental limitation in today’s proxies, in that many are extremely powerful and highly performant but challenging to extend.
Proxy-Wasm is an emerging specification that extends the capabilities of WebAssembly (Wasm) to the realm of networking. It allows developers to write and deploy WebAssembly modules (referred to as "filters") that can be inserted into the request path of proxies, such as HTTP servers, API gateways, or service meshes, to manipulate network traffic. Proxy-Wasm is particularly valuable for scenarios where you must implement custom logic, security, or observability features in your network infrastructure.
Proxy-Wasm is made of two complementary counterparts: a *host ABI* and an *SDK library. *
The proxy ABI exposes low-level bits of the proxy to Proxy-Wasm SDK library used to write the filters. All filters are built atop the SDK library's abstractions, themselves powered by the ABI and the underlying runtime. There are currently Proxy-Wasm SDKs available in AssemblyScript, C++, TinyGo, Rust.
For the full discussion, consider reading Kong’s [What is Proxy-Wasm Documentation](https://github.com/Kong/ngx_wasm_module/blob/main/docs/PROXY_WASM.md#what-is-proxy-wasm)What is Proxy-Wasm Documentation.
Continuing with the original example, the experience would be:
But, in order for all this to happen, the proxy must implement and expose the Proxy-Wasm ABI. So, how did Kong make this happen?
Kong under the hood runs Nginx, and relies on OpenResty to provide the Kong capabilities we all love. OpenResty is highly performant, written in Lua, and uses LuaJIT, a Just-In-Time (JIT) compiler, and provides a rich set of libraries to develop all the key Kong features (highlighted in blue in the diagram below).
In order to also provide support for Proxy-Wasm, the Kong engineering team built an **ngx_wasm module **that implements the Proxy-Wasm specification and sits, metaphorically speaking, alongside the LuaJIT VM.
With this, Kong platform engineers can now write “filters” in the Proxy-Wasm ecosystem to manipulate and/or interact with the API requests that are proxied through the gateway.
Just like the custom Lua plugins, a Proxy-Wasm filter provides an HTTP context with entry points into the request/response lifecycle of nginx phases. In the diagram below, we’ve summarized the HTTP context for you to give you an idea of the correlation between a custom Lua plugin and a filter.
The answer is yes. But, what happens is in each request phase described above, the Lua plugins are executed ***before*** the filter.
This is very important to understand because this will most likely be a very common occurrence in production. For example, you will want to use Kong’s OIDC plugin and a custom wasm filter simultaneously.
You might ask yourself, "Why should I waste my time right now to understand WebAssembly?" Here's why:
1. The Kong Gateway is more extensible, and with WebAssembly, the filters run in a sandboxed VM.
2. Write once, run everywhere. Theoretically, a Proxy-Wasm filter that works on Kong Gateway will work on Envoy, and vice versa with no code changes. In fact, this was proven during the Kong Builders episode [A Practical Application of WebAssembly + Kong Gateway](https://www.youtube.com/watch?v=xPjh2eeMBQA)A Practical Application of WebAssembly + Kong Gateway.
That is pretty cool. Can you see the possibilities start to unfold?
In this article, we've touched upon the intricacies of building filters using WebAssembly and Proxy-Wasm, and witnessed firsthand how this combination elevates the potential of Envoy, Kong Gateway, and Kuma to unprecedented heights. But this is just the beginning. As the ecosystem continues to evolve, so too will the challenges we face, demanding even more versatile solutions.
As we wrap up, remember: in the ever-changing world of microservices, innovation doesn't wait. But with WebAssembly and Kong Gateway in your toolkit, we're not just keeping pace but leading the charge.
Onwards!
P.S. Stay tuned for the November episode of Kong Builders where we continue to explore Proxy-Wasm with Go and Kong Gateway.
In the meantime, let’s point you to some Kong quickstarts.
And, for more examples of filters that you can test on Kong, look to tetratelab’s list of examples on GitHub: [tetratelab/proxy-wasm-go-sdk](https://github.com/tetratelabs/proxy-wasm-go-sdk/tree/main/examples)tetratelab/proxy-wasm-go-sdk.
In January 2024, consumers in the United Kingdom made a record-breaking 14.5 million open banking payments. This milestone shows how dramatically the financial services industry has changed. It's the result of years of regulatory work that kicked of
[](https://konghq.com/blog/learning-center/guide-on-open-banking)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C
[](https://konghq.com/blog/engineering/dedicated-cloud-gateways-managed-redis-multi-cloud)
The example below shows how an AI agent can be built using Volcano SDK with minimal code, while still interacting with backend services in a controlled way. The agent is created by first configuring an LLM, then defining an MCP (Model Context Prot
[](https://konghq.com/blog/engineering/secure-ai-agents-volcano-sdk-kong-mcp-proxy)
In this episode of Kongcast , I spoke with Grant McKeen and Jonathan White from IntegrationWorks about how open banking and BIAN (Banking Industry Architecture Network) work with Kong Gateway to create simplicity from complexity in the ba
[](https://konghq.com/blog/enterprise/open-banking-bian)
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
[](https://konghq.com/blog/product-releases/multicloud-cloud-gateways-managed-redis-cache)