We’ve been building HTTP APIs for system integration for 25+ years. Roy Fielding proposed REST in 2000, and although our architectures are more varied, one common element remains: the network.

These networks that connect people, software, and devices through the Internet are true marvels of technology. We have devised incredible ways to use them. We stream our content, purchase our groceries, hail our cabs, and prompt increasingly capable AI systems to answer our questions — which then make even more network requests themselves to meet our demands.

When it comes to integrating or extending software systems, the network allows fully decoupled peers to exchange data and work together, busily passing messages back and forth. System A notifies System B, which in turn needs to update data in System A and call some additional APIs after it analyzes new data and decides what to do next. All that’s necessary is for the maintainers of both systems to pick a transport encoding (REST, GraphQL, gRPC, or others) and agree on an interface defined in terms of that encoding.

If you’re reading this, you’ve probably built something that works just like that — or certainly have used something that does! It’s a time-tested pattern for API architecture and has served us well.

But, What About When It Doesn’t?

What about when network latencies between Systems A and B start to add up? Making a dozen or so requests across the Internet from A to B isn’t free, and even the speed of light can’t beat ~40ms to cross the United States. Toss in time for authorization, data transfer, re-negotiating TLS if a connection is reset, head-of-line blocking, and reconnects: none of which count the actual time computing the work by System A or B!

Figure 1. A complex HTTP API-based integration, where multiple cross-system requests are needed.

What about when regulations impact where data can go? If System A is in the EU and System B is in the US, can data be moved from A to B? How can my system integrate across these lines? Even within the same legal jurisdiction, consider financial institutions with sensitive data management and exfiltration concerns. It’s unlikely the data an integrator is really interested in is making its way out via HTTP APIs.

But why are we okay with paying this cost? Right now, the separation helps us scale the construction of large systems across multiple small teams of engineers. It reduces the scope of agreements they have to make by reducing the amount of trust they have to extend to other teams. Security, isolation, and redundancy can be taken care of at the network level.

We pay the cost because we don’t have better tools to build with.

Enter WebAssembly

Born of the browser, and a W3C standard, WebAssembly (Wasm) made it possible to run code written in other languages alongside JavaScript on the web. Web applications could now execute compact, efficient, binary modules at near-native speed, enabling complex desktop software like Photoshop and AutoCAD to run in a browser. A key to Wasm’s success is its security model, which by default disallows any code to make network requests, read or write files, or have any information about its surrounding host environment. Wasm runs in a fully isolated, sandboxed virtual machine, only capable of what the host running it allows.

What Does This Mean for APIs and Systems Integration?

A few years ago, Wasm broke free from the browser and has been implemented several times as a standalone virtual machine. This means Wasm modules can be run anywhere a capable virtual machine can run: on a desktop, game console, server, IoT device, edge platform, and even TVs and smartwatches. Running Wasm embedded within a server application means that arbitrary, untrusted code can safely execute inside our software, running dynamic code in-process.

It turns out that Wasm isn’t about bringing the capabilities of other languages to the browser — its true strength is about bringing the capabilities of the browser to your languages.

Let’s revisit our scenario above, where Systems A and B are integrated over an HTTP API. Rather than requiring a dozen hops across the Internet, what if System A could actually run System B’s code, but only the parts it needs to handle the integration? Here’s a simple theoretical idea to illustrate this:

1. Stripe gets a credit card charge request for an Acme Corp. customer.
2. Stripe loads Acme Corp.’s Wasm plugin to call the before_charge_action function, which returns some data about the purchase.
3. Acme Corp.’s plugin must first look up the customer’s past purchases on Stripe’s API. Since the plugin is still in Stripe, this is a local function call — no Internet needed! This happens in as little as 5-7 nanoseconds! (For context, that 40 millisecond intracontinental hop is 40,000,000 nanoseconds.)
4. With the purchase data, the plugin continues and detects that ten similar purchases have been made in the past 30 days.
5. Because of this, the plugin is coded to send an email with a loyalty discount for the customer’s next purchase, so it makes another function call to Stripe to get the email address and customer name (managed in Stripe’s database) to fill out the email template.
6. Stripe has provided a send_email function to the plugin, so it can pass email content and send directly from Stripe’s highly reliable email service.
7. The plugin returns data to Stripe, and the charge is executed successfully. Immediately afterward, the customer sees a friendly discount email in their inbox.

Figure 2. A complex Wasm plugin integration, similar to the process of Figure 1 (above) between System A and System B, but where all logic is local to the event originator, e.g., Stripe.

We accomplished all of this without making a single API call over the Internet between two systems. What would have likely taken too long to execute in the middle of a payment transaction took just nanoseconds being local function calls. Additionally, all the transaction information and customer data remained on Stripe’s servers without the risk of exfiltration or PII being accidentally leaked.

Real-World WebAssembly Integrations

In fact, many such systems work like this today, using WebAssembly to power the secure customer code execution. Take Figma, widely loved as a design tool for creating high-fidelity web and mobile application mockups. Figma runs 3rd party plugin code inside a Wasm runtime to enable its customers to extend the software with new features and capabilities — freely, without Figma needing to step in and handle feature requests. Figma has both web and desktop applications, so are plugin developers forced to implement a plugin for each platform? No! Wasm runs identically across these platforms, so the same plugins work no matter where Figma is running.

Another brilliant implementation of this integration pattern is from Shopify. The e-commerce market leader has been running Wasm in production for years now, powering its next-generation app marketplace: Shopify Functions. Developers can build plugins, which merchants install into their stores, to run directly within Shopify’s infrastructure. This provides far deeper integration access into the platform, and with no network latency, integrations run fast — making it possible to inject custom behavior even in the checkout path, where every minor delay could mean lost sales.

The benefits don’t stop at integration speed and depth. Shopify is also protecting its customers by exposing more customization directly on the platform versus via HTTP API. Recently, a Shopify app developer admitted to a sizable data leak, exposing Shopify customer data it had gathered from merchants using its apps. Since these apps were calling HTTP APIs and storing customer data on third-party servers, Shopify had no control over the security posture of this developer. Keeping all third-party code on Shopify using WebAssembly plugins instead means they have infinitely more control over scenarios like this and would have prevented this unfortunate leak.

Where HTTP APIs move data to be used in computing environments, Wasm presents a revolutionary shift to move logic to data environments. Flipping the relationship, keeping data stationary and moving logic, enables new integrations that we’re only beginning to leverage.

Looking Forward

The HTTP API isn’t going away, not anytime soon. But, empowered with new technology and ways to integrate systems means it’s time to consider some alternatives or look at ways to incrementally enhance the status quo. Bringing the security and speed of Wasm into your integration architecture has many benefits, and we’re seeing adoption rise rapidly.

Consider WebAssembly when you’re thinking about making more secure integration APIs. Your customers will appreciate the flexibility and ease of integration it brings to your platform. Suffice it to say that Wasm is early in its journey in the API and systems integration space, but is already proving its value at companies large and small.