Extending Your API Gateway with WebAssembly Plugins

Yilia Lin

Yilia Lin

March 19, 2026

Technology

Introduction

The digital landscape demands ever-increasing flexibility and performance from our infrastructure. Recently, a fascinating discussion on Hacker News, "Show HN: Sub-millisecond VM sandboxes using CoW memory forking", highlighted the innovative approach of using Copy-on-Write (CoW) memory forking to achieve incredibly fast virtual machine sandboxes. This topic resonates deeply with the challenges developers face when extending their API gateways: how to introduce custom logic and features without compromising performance or stability.

The Core Problem/Concept: Safe and Performant Extension

Extending core infrastructure components like API gateways often presents a dilemma. On one hand, custom logic is essential for tailored functionalities such as advanced authentication, complex routing, data transformation, or integration with proprietary systems. On the other hand, directly embedding custom code can introduce significant risks:

  • Stability Issues: A bug in custom code can crash the entire gateway, leading to service outages.
  • Performance Degradation: Inefficient custom logic can introduce latency, negating the benefits of a high-performance gateway.
  • Security Vulnerabilities: Poorly written extensions can create security holes, exposing the system to attacks.
  • Resource Contention: Uncontrolled resource usage by extensions can starve other critical gateway functions.

The Hacker News discussion on sub-millisecond VM sandboxes points towards a solution: isolating custom code in lightweight, high-performance environments. This is precisely where WebAssembly (Wasm) shines in the context of API gateways.

The API7/APISIX Connection: WebAssembly Plugins

Apache APISIX, a dynamic, real-time, high-performance API gateway, addresses this core problem through its robust support for WebAssembly (Wasm) plugins. APISIX leverages Wasm to provide a secure, efficient, and language-agnostic way to extend its functionality. Instead of writing plugins directly in Lua (APISIX's native language), developers can write custom logic in various languages like Rust, Go, C/C++, or AssemblyScript, compile them to Wasm bytecode, and then run them within a sandboxed environment in APISIX.

This approach offers several key advantages:

  • Enhanced Security: Wasm modules run in a sandboxed environment, isolated from the host process. This prevents malicious or buggy code from affecting the core gateway.
  • High Performance: Wasm is designed for near-native performance, making it ideal for high-throughput API gateway operations. The lightweight nature of Wasm runtimes, similar to the sub-millisecond VM sandboxes discussed on HN, ensures minimal overhead.
  • Language Agnosticism: Developers can use their preferred programming languages, significantly lowering the barrier to entry for custom plugin development.
  • Portability: Wasm modules are highly portable and can run consistently across different environments.

API7 Enterprise, built on Apache APISIX, further enhances these capabilities by providing enterprise-grade features, support, and management tools for Wasm plugins, making it easier for organizations to adopt and scale this powerful extension mechanism.

Step-by-Step Hands-on Example: A Simple Wasm Plugin in APISIX

Let's walk through an example of creating and deploying a simple Wasm plugin in Apache APISIX. We'll create a plugin that adds a custom header to all requests.

Architecture Diagram

graph TD
    A[Client] --> B(API Gateway - Apache APISIX)
    B --> C{Wasm Plugin: Add Custom Header}
    C --> D[Upstream Service]
    B -- Request Flow --> C
    C -- Modified Request --> D

Prerequisites

Before you begin, ensure you have:

  • Docker installed (for running APISIX and an upstream service).
  • curl installed (for interacting with the APISIX Admin API).
  • A Wasm toolchain (e.g., wasm-pack for Rust, or tinygo for Go) if you want to compile your own Wasm module. For this example, we'll use a pre-compiled Wasm module.

1. Start Apache APISIX and an Upstream Service

First, let's set up APISIX and a simple HTTP server using Docker Compose. Create a docker-compose.yml file:

version: "3"
services:
  apisix-dashboard:
    image: apache/apisix-dashboard:2.15.0-alpine
    container_name: apisix-dashboard
    ports:
      - "9000:9000"
    volumes:
      - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml
    networks:
      - apisix
    depends_on:
      - apisix

  etcd:
    image: bitnami/etcd:3.5.6
    container_name: etcd
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd:2379
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
    networks:
      - apisix

  apisix:
    image: apache/apisix:2.15.0-alpine
    container_name: apisix
    ports:
      - "9080:9080"
      - "9081:9081"
      - "9443:9443"
      - "9180:9180"
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
      - ./apisix_conf/wasm:/opt/apisix/wasm
    networks:
      - apisix
    depends_on:
      - etcd

  upstream-service:
    image: kennethreitz/httpbin
    container_name: upstream-service
    ports:
      - "8080:80"
    networks:
      - apisix

networks:
  apisix:
    driver: bridge

Create a minimal apisix_conf/config.yaml:

# apisix_conf/config.yaml
apisix:
  node_listen: 9080
  admin_listen: 9180

plugins:
  - wasm

Create a directory for Wasm modules: mkdir -p apisix_conf/wasm.

Now, start the services:

docker-compose up -d

2. Upload the Wasm Plugin

For this example, we'll use a simple Wasm plugin that adds a header. You would typically compile your own, but for demonstration, let's assume you have a add-header.wasm file. For instance, a Rust program compiled to Wasm might look like this (simplified):

// src/lib.rs
#[no_mangle]
pub extern "C" fn _start() {
    // Logic to add a header
}

Place your add-header.wasm file into the apisix_conf/wasm directory. If you don't have one, you can find examples online or compile a simple one. For the sake of this tutorial, let's assume a add-header.wasm exists in apisix_conf/wasm that adds X-Wasm-Added: True header.

3. Configure APISIX to Use the Wasm Plugin

Now, let's configure a route in APISIX to use our Wasm plugin. We'll create an upstream pointing to our upstream-service and a route that applies the wasm plugin.

curl -i "http://127.0.0.1:9180/apisix/admin/routes/1" \
  -X PUT \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" \
  -d '{
  "uri": "/wasm/*",
  "plugins": {
    "wasm": {
      "conf": {
        "path": "/opt/apisix/wasm/add-header.wasm",
        "name": "add-header"
      }
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "upstream-service:80": 1
    }
  }
}'

Note: Replace edd1c9f034335f136f87ad84b625c8f1 with your actual Admin API key if you've changed it in config.yaml.

4. Test the Wasm Plugin

Now, send a request to APISIX through the configured route:

curl -i http://127.0.0.1:9080/wasm/headers

You should see the X-Wasm-Added: True header in the response, indicating that our Wasm plugin successfully intercepted and modified the request before it reached the upstream service.

Conclusion

The discussion around sub-millisecond VM sandboxes on Hacker News underscores a critical need for efficient and isolated execution environments. WebAssembly, as implemented in Apache APISIX and enhanced by API7 Enterprise, provides a powerful and elegant solution for extending API gateway functionality. It allows developers to build custom logic with confidence, ensuring high performance, robust security, and unparalleled flexibility, all while leveraging their preferred programming languages. This approach not only mitigates the risks associated with direct code integration but also unlocks new possibilities for building highly customized and resilient API infrastructures.

Tags:
WebAssembly
API Gateway
Plugins