In his blog post titled “Beyond the HTTP API: WebAssembly and the Future of Systems Integrations” Steve Manuel highlights next generation systems integrations with examples from Shopify and Figma. The article highlights an important component to next-gen integrations by Wasm in moving logic to data environments, versus moving data to be used in computing environments with HTTP APIs. ZeroSync takes this a step further by providing flexible workflow orchestration for integrations. Engineers can now break down integration requirements into Wasm modules, then mix and match those modules for any given workflow needs.

Modern Integration Challenges

Integration engineers are familiar with most of the challenges in building and maintaining API integrations. Modern integrations require developers to custom-build or use multiple SDKs because systems and applications are built with different programming languages. Additionally, systems and applications use various communication protocols, such as HTTP and gRPC, and have different plugin architectures for enabling integrations, which makes the process highly differentiated. There is also the added challenge of regression testing systems every time a new integration is implemented. Once the integration is in place, it requires ongoing maintenance. If the system or application changes, the integration needs to be updated, which can become resource-intensive and significantly increase engineering costs to maintain system functionality.

Orchestrate Integrations with ZeroSync & Extism

ZeroSync’s open-source integration workflow solution, Deadlift, addresses these challenges by providing a low-level agent that runs integration code with Extism. A Deadlift agent does two functions: it provides an interface for registering the modules and workflows it should run, and it enables those integration payloads to be executed and sent to other Deadlift agents for optimal distributed computing. Utilizing the Extism Wasm approach is essential for providing an ergonomic development experience for integration module programming, allowing engineers to write code as they always have, while automatically gaining the benefits of portability, security, and improved performance.

Let’s take a look at the example Steve explores in the blog post with Acme Corp and Stripe.

“System 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?” Steve then dives into a demonstration of how an integration can occur without making a single API call over the Internet between two systems, but two questions remain.

• How does Stripe communicate data about what the plugin did and when; e. g. what discounts were sent back to Acme Corp?
• How can Acme Corp receive and process that data as a single unified workflow with Stripe; e. g. how can Stripe and Acme Corp collaborate on this integration?

 

Let’s dive into the example as a refresher.

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 customers 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 400 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 the email address and customer name (managed in Stripes 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.

Stripe’s customers would likely want to know when and how their plugins are running. Acme Corp wants to know how many discounts have been sent out and analyze that data so they can adjust discount percentages or enable different incentives to their customers. Additionally, Acme Corp and Stripe want to be able to observe and manage this workflow with minimal overhead. ZeroSync’s Deadlift solution solves these integration logic management and workflow orchestration problems.

In the above example, Acme Corp has no visibility into the data from the integration, and there is no way to easily setup a workflow between Acme Corp and Stripe. Acme Corp knows they benefit from the interaction of data with Stripe, and need to set up a workflow to receive and handle this data.

Rethinking this workflow with ZeroSync’s Deadlift:

1. Stripe gets a credit card charge request for an Acme Corp customer. Stripe creates a Deadlift workflow with Acme. The Stripe/Acme Corp Deadlift workflow detects that there is an Acme Corp credit card charge request workflow.

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 customers past purchases on Stripe’s API.

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 the email address and customer name (managed in Stripes 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. Stripe then broadcasts information about the discount back to Acme Corp as a Deadlift event.

8. Acme Corp then receives the Deadlift event with the processing information, and aggregates it into the customer satisfaction service to analyze the effectiveness of the incentive as the next Deadlift workflow step.

This next-gen integration approach with ZeroSync’s Deadlift while utilizing Extism enables Stripe’s ~1.5 million active websites to have in-depth data that was used during the integration, such as logs, traces, and user data, after the credit card charge request was made. Stripe and its customers can set up Deadlift workflows and minimize integration latency while also providing both organizations with valuable data about the integration itself. Extism solves many problems with HTTP integrations, and utilizing Deadlift on top of this provides a new integration paradigm altogether. With Deadlift and Extism, Acme Corp and Stripe can create and maintain this workflow.

Next-Gen Integrations: Solving Tomorrow’s Challenges, Today

As Steve mentions, “the HTTP API isn’t going away, not anytime soon” but Extism with ZeroSync offers an incredible alternative to bring visibility, security, speed, and composability to your integrations. The combined growth of AI and machine learning, along with the continued growth of SaaS is driving an increasingly interconnected digital ecosystem. Integrated systems will play a crucial role in driving massive growth. Companies don’t need to stick with the status quo or outsource integrations to third party teams across the world. Wasm is already proving its value and Extism with ZeroSync as next-gen integrations are already solving tomorrow’s challenges, today.