Leveraging WASM to Improve Quality and Flexibility of the API Plugin Ecosystem...

### Overview In this talk, Rohan Deshpande, Managing Director and Senior Engineer at Goldman Sachs, details how the firm transitioned parts of its API platform plugin ecosystem to WebAssembly (Wasm). Goldman Sachs operates an API platform handling millions to hundreds of millions of requests per day across multiple gateway runtimes such as Envoy, NGINX, and Apache. To overcome developer bottlenecks, poor test coverage, and the constraints of writing plugins in C++ or Lua, the team evaluated and adopted Wasm. This shift allows engineers to write plugins in Go, integrate standard SDLC security tooling, and safely execute logic across multi-tenant API gateways.

### Key Topics - **API Gateway Extension Challenges:** API filters and plugins generally fall into vendor-provided, centralized platform plugins (e.g., OpenID, metering), or tenant-specific custom plugins. Relying on platform teams caused an 18-month backlog, while writing custom plugins in C++ or Lua lacked widespread developer adoption and had poor test coverage (10–15%). - **Wasm Evaluation:** The platform team sought binary sandboxing, portability across Linux environments, language flexibility, and safe multi-tenancy. Wasm emerged as the ideal target, particularly driven by Envoy's Wasm support. - **Proof of Concept (PoC):** The team implemented an account number redaction plugin (matching 9-character account numbers and masking the first 5 characters with asterisks) using Go, the proxy-wasm Go SDK, and the TinyGo compiler. - **SDLC Integration:** The Wasm approach enabled integration into enterprise CI/CD workflows, achieving 83% unit test coverage, dependency vulnerability scanning, IP scanning, and containerized deployment. - **Production Rollout & Trade-offs:** Over 55% of relevant plugins were converted over a nine-month evaluation period, heading toward a phased blue/green production deployment in Q4.

### Technical Details - **Tooling & Compilation:** Go source code is compiled to Wasm modules using TinyGo, which targets small binary sizes. To solve slower compilation times in CI/CD, the team sharded and parallelized builds (e.g., building five plugins per host). - **Code Sharing:** Structuring core business logic separately from gateway shim/wrapper code enabled 35% immediate code reuse across different proxy runtimes without redesign. - **Performance Impact:** Out-of-the-box Wasm execution caused roughly a 14% drop in throughput per host compared to in-process C++ or Lua execution. This degradation stemmed from runtime context transitions and cold starts, though it outperformed the team's initial 25% degradation estimate. The team aims to tune performance down to a 5–8% hit. - **Telemetry & Testing:** Observability relies on tracking 400/500 errors, overall latency, and internal plugin dwell times (time spent executing logic vs. runtime interface overhead). Deshpande stresses investing in integration testing to catch memory issues and ABI incompatibilities that escape build-time checks.

### Takeaways - Wasm enables mainstream programming languages (like Go) to replace complex or niche gateway scripting without sacrificing multi-tenant security. - Moving to compiled Wasm unlocks enterprise CI/CD practices—such as automated unit testing, code coverage thresholds, and CVE/IP scanning—for API gateway filters. - Teams adopting Wasm must consciously weigh developer velocity and code reuse against runtime throughput hits, and must build automated test suites to keep pace with the rapidly evolving Wasm specification and tooling.