Forem: Jasmine Mae

A Bridge over Troubled Water: Sending Azure Alerts to Slack with Spin

Jasmine Mae — Mon, 22 Sep 2025 14:42:18 +0000

By: Kate Goldenring

Improving the visibility of infrastructure alerts is key to reducing time to response. This is why many operations teams integrate alerts with their team messaging platforms. At Fermyon, we are one of those teams. We pull alerts from all our cloud providers and services into Slack channels. Recently, I ran into a challenge while trying to bridge Azure service alerts into Slack. Azure and Slack expect different JSON formats for messages, which meant I couldn’t simply drop a Slack incoming webhook URL into the Azure Portal. I needed an application to bridge these JSON differences, so I created Azure Slack Bridge, a lightweight, HTTP-triggered transform function. This blog will walk through how to deploy the Azure Slack Bridge Spin application and equip you to build your own service bridges using Spin.

Using Spin as a Service Bridge

Rather than learning a new Azure product, such as Azure Logic Apps, I chose to build a simple Spin application to act as middleware between Azure and Slack. Azure formats alert payloads using its Alert Common Schema, while Slack expects JSON payloads with a single text field. I needed a function to bridge these two formats.

Azure Monitor → Azure Slack Bridge (Spin App) → Slack
     │                        │                  │
   (Complex               (Parses &           (Simple
    JSON)                 Transforms)         Message)

Another benefit of this approach is portability and extensibility. Because the bridge is just a Spin application, it isn’t tied to Azure-specific tooling. If you’re operating in a multi-cloud environment, you can easily repurpose or extend the same bridge application to handle alerts from Amazon Web Services, Google Cloud Platform, or other cloud services without having to learn the quirks of yet another managed integration product. This gives you a consistent, reusable way to transform alerts into a Slack-compatible message across cloud providers.

Cloud Service  →  Slack Bridge (Spin App)  →  Slack
     │                      │                   │
   (JSON)               (Parses &            (Simple
                        Transforms)          Message)

Abstracting further, we arrive at a general model where Spin applications resolve JSON disparities.

Origin Service → Bridge (Spin App) → Destination Service
     │                 │                      │
 (JSON A)           (Parses &             (JSON B)
                    Transforms)

So regardless of whether you use Slack or Azure, this blog should give you a toolkit for using Spin applications to bridge your services.

Azure Slack Service Bridge Implementation

The Azure Slack Bridge Spin application is a HTTP-triggered WebAssembly component written in Rust. Its HTTP handler transforms an Azure alert into a Slack message in just five steps:

#[http_component]
fn handle_slack_bridge(req: Request) -> anyhow::Result<impl IntoResponse> {
    // 1) Get the Slack webhook URL from a dynamic application variable 
    let slack_webhook_url = variables::get("slack_webhook_url")?;

    // 2) Parse the origin service JSON message from the HTTP request body
    let azure_alert = match serde_json::from_slice::<AzureAlert>(req.body()) {
        Ok(alert) => alert,
        Err(e) => {
            eprintln!("Failed to parse Azure alert: {}", e);
            return Ok(Response::builder()
                .status(400)
                .body(format!("Invalid alert payload: {}", e))
                .build());
        }
    };

    // 3) Format the origin message for Slack
    let slack_text = format_alert_message(&azure_alert);

    // 4) Send the message to Slack
    let slack_message = SlackMessage { text: slack_text };

    let request = Request::builder()
        .method(Method::Post)
        .body(serde_json::to_vec(&slack_message)?)
        .header("Content-type", "application/json")
        .uri(slack_webhook_url)
        .build();

    // 5) Return the result back to the origin service
    let response: Response = spin_sdk::http::send(request).await?;
    if *response.status() != 200 {
        return Ok(Response::new(500, "Failed to send to Slack"));
    }
    Ok(Response::new(200, ""))
}

Using the Azure Slack Bridge Application to Monitor Cosmos DB

Let’s walk through a common alerting example from Azure Cosmos DB. Cosmos DB is Azure’s fully managed database and one of Spin’s supported Key Value Store providers. This means you can deploy SpinKube to Azure Kubernetes Service and enable applications to use key-value stores with a Cosmos DB backing. With this setup in place, you’d likely want to monitor your infrastructure to track performance and catch issues early.

One common Cosmos DB metric to monitor is a threshold of 429 HTTP status codes, which are emitted when requests are rate-limited. For example, you may want an alert when 100 or more requests are throttled. Let’s see how to bridge that alert to Slack with the Azure Slack Bridge Spin application.

Step 1: Create an Incoming Slack Webhook

Slack supports incoming webhooks to post messages from external services. After creating a webhook, you’ll receive a unique URL to send JSON payloads with simple text messages. Follow this guide to create a Slack app and webhook. Copy the final URL – you’ll set this as the slack_webhook_url variable in the Azure Slack Bridge Spin application.

Step 2: Build and Deploy the Azure Slack Bridge Application

Testing the Application Locally
After installing Spin and creating a Slack incoming Webhook, you can test your application locally. First, build and run the application, setting your Slack Webhook URL as a Spin Variable using the environment variable provider:

git clone https://github.com/kate-goldenring/azure-slack-bridge
cd azure-slack-bridge
SPIN_VARIABLE_SLACK_WEBHOOK_URL="https://hooks.slack.com/services/<...> spin build --up

Next, test your connection to Slack with the example Azure alert payload provided in the repository.

curl -X POST \
  -H "Content-Type: application/json" \
  -d @sample-alert.json \
  localhost:3000

You should see a new message in the Slack channel you configured for the webhook. The message title should be: “⚠️ 🔴 WCUS-R2-Gen2”.

Deploying Your Spin Application
Spin applications can be deployed to any Spin-compatible platform. Many platforms make this process simple with Spin CLI plugins. The following are three options:

Deploy to Fermyon Wasm Functions, a multi-tenant, hosted, globally distributed engine for serverless functions running on Akamai Cloud, using the aka plugin:

Note: Currently, Fermyon Wasm Functions is in limited access, public preview, so you must first fill out this form to request access to the service.

spin aka deploy

Deploy to Fermyon Cloud, a multi-tenant, hosted, functions service, using the cloud plugin:

spin cloud deploy

Your SpinKube cluster, using the the kube plugin:

spin registry push ttl.sh/azure-slack-bridge:24h
spin kube scaffold -f ttl.sh/azure-slack-bridge:24h | kubectl apply -f -

After deploying your application, you should have a URL for your middleware Spin application that you can use when setting up your Alert Group in the next step.

Step 3: Set Up the Azure Alert Pipeline

Follow this Azure tutorial to create an Alert Rule for a threshold of 429 HTTP status codes from Cosmos DB. When creating the rule, link it to an Action Group. This is where you’ll create an Action Group with a Webhook action type. Paste the URL of the deployed application into the URI field of the webhook pane. Be sure to enable the common alert schema for the webhook.

Seeing Alerts in Slack

Now, alerts will be bridged into Slack in clear formatting:

A Bridge over Troubled Water

Bridging Azure alerts into Slack doesn’t need to be complicated. With Spin, you can build lightweight serverless applications that act as middleware between services, transforming JSON payloads, normalizing data formats, and routing events exactly where you need them. While this example focused on Cosmos DB alerts flowing into Slack, the same pattern applies to any Azure service or even other cloud providers.

Try out the Azure Slack Bridge to get started, and then experiment with building your own service bridges to streamline how your team stays informed and responsive.

Introducing wasi-grpc for Spin

Jasmine Mae — Tue, 09 Sep 2025 02:09:09 +0000

By: Brian Hardock

Modern microservice ecosystems often rely on gRPC for efficient, strongly typed communication. gRPC builds on top of HTTP/2, taking advantage of multiplexed streams and binary serialization (Protobuf) to deliver high throughput and low latency.

Until Spin 3.4, Spin components could only make outbound HTTP/1.1 requests. This meant gRPC clients could not run inside Spin directly; developers had to rely on sidecars or proxy services to bridge the gap. That added extra complexity and slowed down applications.

Spin 3.4 introduces outbound HTTP/2 support, enabling components to act as first-class gRPC clients. Spin applications can now call into existing gRPC-based systems, cloud APIs, and service meshes directly, without workarounds.

In this blog post, we will walk through a tutorial showing how to build a Spin component in Rust that connects to a simple gRPC service using the new wasi-grpc crate.

Tutorial

For this tutorial, we will be adapting the tonic helloworld example client to execute in Spin. Additionally, for testing, we will run the helloworld server to execute our component against.

Step 1: Create a new Spin app

spin new -t http-rust helloworld-client --accept-defaults

This creates a new helloworld-client directory with a Spin HTTP Rust application. Change into this directory to continue with the tutorial:

cd helloworld-client

Step 2: Setup

First, in Cargo.toml, add the dependencies for working with gRPC, Protobuf, and the wasi-grpc crate:

[dependencies]
anyhow = "1"
prost = "0.13.5"
wasi-grpc = "0.1.0"
spin-sdk =  "4.0.0"
tonic = { version = "0.13.1", features = ["codegen", "prost", "router"], default-features = false}

Next, copy the helloworld proto into your current working directory.

With that in place, we can add our build dependencies for generating code from our proto file. In your Cargo.toml add the following:

[build-dependencies]
tonic-build = { version = "0.13.1", features = ["prost"] }

And finally we can add the build.rs which will generate our gRPC client from the helloworld proto:

// In build.rs

fn main() {
    tonic_build::configure()
        .build_transport(false)
        .compile_protos(&["helloworld.proto"], &[""])
        .unwrap();
}

Let’s implement!

In src/lib.rs, let’s start by pulling in the generated code from executing our build.rs:

use hello_world::greeter_client::GreeterClient;
use hello_world::HelloRequest;

pub mod hello_world {
    tonic::include_proto!("helloworld");
}

Next let’s pull in the wasi_grpc::WasiGrpcEndpoint type which implements tower_service::Service. This type creates a bridge between tonic and wasi-hyperium which is what wasi-grpc uses under the hood for sending outbound HTTP requests.

use wasi_grpc::WasiGrpcEndpoint;

NOTE: It was decided to use wasi-hyperium as the underlying mechanism for sending outbound requests because the spin-sdk currently has certain limitations with respect to outbound streaming.

And finally we can implement our request handler:

#[http_component]
async fn handler(_req: http::Request) -> anyhow::Result<impl IntoResponse> {
    let endpoint_uri = "http://[::1]:50051".parse().context("Failed to parse endpoint URI")?;
    let endpoint = WasiGrpcEndpoint::new(endpoint_uri);
    let mut client = GreeterClient::new(endpoint);

    let request = Request::new(HelloRequest {
        name: "World".to_string(),
    });

    let message = client
        .say_hello(request)
        .await?
        .into_inner()
        .message;

    let response = http::Response::new(200, message);

    Ok(response)
}

NOTE: For simplicity, we are using a hardcoded endpoint (“http://[::1]:50051”) to communicate with our local gRPC server that implements the GreeterService. For production applications it is recommended to use application variables to inject in the value of the address at run/deploy time.

Putting this all together, the final code in src/lib.rs looks like this:

use anyhow::Context;
use spin_sdk::http::{self, IntoResponse};
use spin_sdk::http_component;
use tonic::Request;
use wasi_grpc::WasiGrpcEndpoint;

use hello_world::greeter_client::GreeterClient;
use hello_world::HelloRequest;

pub mod hello_world {
    tonic::include_proto!("helloworld");
}

// Spin HTTP component
#[http_component]
async fn handler(_req: http::Request) -> anyhow::Result<impl IntoResponse> {
    let endpoint_uri = "http://[::1]:50051".parse().context("Failed to parse endpoint URI")?;
    let endpoint = WasiGrpcEndpoint::new(endpoint_uri);
    let mut client = GreeterClient::new(endpoint);

    let request = Request::new(HelloRequest {
        name: "World".to_string(),
    });

    let message = client
        .say_hello(request)
        .await?
        .into_inner()
        .message;

    // Return gRPC response as HTTP response body for the Spin component
    let response = http::Response::new(200, message);

    Ok(response)
}

Let’s take it for a Spin!

As mentioned earlier, we will be using the helloworld server to execute our app against. The easiest way to run this would be to clone the tonic repository and run the helloworld server:

$ gh repo clone hyperium/tonic
$ cargo run --bin helloworld-server
...
GreeterServer listening on [::1]:50051

Next, we will want to configure our Spin app so that our component can communicate with the our server running at [::1]:50051. In your spin.toml, you’ll want to add the following:

[component.helloworld-client]
...
allowed_outbound_hosts = ["http://[::1]:50051"]

Now that we have our server running and app properly configured, let’s spin up our application and send it a request to execute our new component:

$ SPIN_OUTBOUND_H2C_PRIOR_KNOWLEDGE=[::1]:50051 spin up --build

NOTE: The SPIN_OUTBOUND_H2C_PRIOR_KNOWLEDGE environment variable is to tell the Spin runtime that we are intending to use HTTP/2 without TLS. If you’re running this example against a server with TLS enabled you can omit this variable.

And finally, let’s send a request to our app:

$ curl localhost:3000/
Hello World!

Conclusion

Spin 3.4’s outbound HTTP/2 support removes one of the biggest barriers to using Spin in modern service-oriented systems: direct gRPC client support. With the help of the wasi-grpc crate, components can now:

Call gRPC microservices directly without sidecars
Integrate with APIs built on gRPC
Leverage high-performance streaming patterns as first-class citizens in Spin

The example above uses the simple helloworld service, but the same approach applies to more advanced services — including streaming APIs. For inspiration, check out the routeguide-client in the wasi-grpc repository.

If you have any questions, we’d love to help over in the Spin CNCF Slack channel. Hope to see you there!

OpenAPI Documentation for Spin Apps with Rust

Jasmine Mae — Thu, 28 Aug 2025 16:18:40 +0000

By: Thorsten Hans

Generating and exposing machine- and human-readable documentation for RESTful APIs is a must, and those built with Spin are no exception. The OpenAPI Specification (OAS) is the de-facto standard when it comes to documenting RESTful APIs. In this article we will explore how one could generate OAS-compliant documentation from within Spin applications written in Rust.

Before diving straight into a practical example, we’ll do a quick refresher on what OAS actually is.

What is the OpenAPI Specification (OAS)

The OpenAPI Specification (OAS) serves as a universal, language-agnostic standard for describing the structure and features of RESTful APIs. By establishing a clear, machine- and human-readable contract, OAS allows developers, API consumers, and tools to understand available endpoints, request and response schemas, authentication methods, and more.

Leveraging the OAS description, teams can also provide interactive documentation UIs, generate client SDKs for various programming languages, server mocks for rapid prototyping, and even automated tests for end-to-end validation.

The OpenAPI description not only streamlines onboarding for new developers but also ensures that your API remains consistently documented and discoverable throughout its lifecycle, making OAS an indispensable tool for modern API development.

A Practical Guide To OpenAPI Documentation

Prerequisites and Setup

To follow along with the instructions and snippets shown as part of this article, you must have the following things installed on your development machine:

Spin CLI version 3.3.1 or later (see installation instructions)
Rust version 1.86.0 or later including the wasm32-wasip1 target (see Rust and target installation instructions)
Git CLI (see installation instructions)
An Editor

We will use an API that implements simple “to-do” list functionality as a starting point. You can find the source code on GitHub at https://github.com/ThorstenHans/spin-todo-api.

Clone the repository and build the Spin application:

# Clone the Spin application from GitHub
git clone git@github.com:ThorstenHans/spin-todo-api.git

# Move into the application directory
cd spin-todo-api

# Build the Spin application
spin build

If your development machine has all the necessary tools and is set up correctly, you should see output along the lines of this:

Building component spin-todo-api with `cargo build --target wasm32-wasip1 --release`

# ...
# ...

Finished building all Spin components

Exploring the ToDo-API

Now that we’ve successfully built our application, let’s take a look at it’s functionality. The pre-coded ToDo-API is a RESTful HTTP API that exposes the following endpoints:

GET /api/todos - Retrieve a list of all ToDo-items
GET /api/todos/:id - Retrieve a particular ToDo-item using its identifier
POST /api/todos - Create a new ToDo-item
POST /api/todos/:id/toggle - Toggle a ToDo-item using its identifier
DELETE /api/todos/:id - Delete a ToDo-item using its identifier

ToDo-items are stored and retrieved from a key-value store (see src/domain/todo.rs) which is automatically managed by the runtime (Spin, Fermyon Wasm Functions or Fermyon Cloud) on your behalf.

On top of the default dependencies, the following crates have been added to the ToDo-API:

uuid (features: v4, serde) - Used to generate identifiers for ToDo-items
serde (features: derive) - Used to serialize and deserialize Rust structs
serde_json - JSON support for serde
url - Which we’ll use later to parse URLs

Meet the `utoipa` Crate

The utoipa crate is designed to simplify the process of generating OpenAPI documentation directly from within your codebase. By leveraging macros, utoipa automatically produces a comprehensive OAS description according to the OAS specification.

This allows us to keep the documentation of our RESTful API in sync with the actual implementation, while requiring minimal effort.

To add utoipa with its optional uuid feature as a dependency use the cargo add command as shown below:

# Run the following command from the spin-todo-api directory

# Add utoipa with uuid feature as a dependency
cargo add utoipa -F uuid

With the utoipa crate being added as a dependency to the ToDo-API (see Cargo.toml), we can now start documenting our API. Generally speaking, there are three different documentation assets we have to provide:

General API documentation
API request- and response-model documentation
API endpoint documentation

The following sections will guide you through each documentation asset, and provide an example of how to update the implementation.

General API Documentation

You can think of “General API documentation” as fundamental metadata about your RESTful API (such as contact information, license, tags, etc.). We use the #[openapi] macro on a custom Rust struct to specify all static information.

utoipa also supports customizing the “General API documentation” at runtime by either adding custom modifiers (for reusable, modular customizations) or by leveraging the APIs provided by utoipa (for simpler, direct modifications).

We will start with defining all static information using the #[openapi] macro, but will add dynamic customization later in this article. First, we have to create a new struct in src/handlers/docs.rs, which we will decorate using the utoipa::openapi macro. Additionally, we’ll derive from utoipa::OpenApi:

use utoipa::{OpenApi};

#[derive(OpenApi)]
#[openapi(
  info(
    title = "ToDo API",
    description = "An awesome ToDo API",
    terms_of_service = include_str!("../../fake_terms_of_service.txt"),
    contact(
      name = "Fermyon Engineering", 
      email = "engineering@fermyon.com", 
      url = "https://www.fermyon.com"
    )
  ),
  tags(
    (name = "todos", description = "ToDo API Endpoints")
  ),
  paths(
    crate::handlers::todo::get_by_id,
  )
)]
struct OpenApiDocs {}

API Request and Response Model Documentation

The ToDo-API provides dedicated request and response models to encapsulate the API from the underlying data structures used for persistence. By using dedicated API models, you can design clean and efficient API contracts and provide fine-grained validation logic.

Documenting your API models helps humans and computers to understand their contextual meaning. With utoipa, documenting these models is done by using the ToSchema derive macro. The ToSchema derive macro integrates seamlessly with Rust doc comments for specifying the title of a particular model and its fields. Also, rename instructions from serde are taken into context as well.

You can use the #[schema] macro to provide samples and perform further customizations:

use serde_json::json;
use utoipa::ToSchema;

/// ToDo-item
#[derive(Serialize, ToSchema)]
#[serde(rename_all = "camelCase")]
#[schema(example = json!({ "id": "059c7906-ce72-4433-94df-441beb14d96a", "contents": "Buy Milk", "isCompleted": false}))]
pub struct ToDoModel {
  /// Unique identifier
  id: Uuid,
  /// ToDo contents
  contents: String,
  /// Is Completed?
  is_completed: bool,
}

API Endpoint Documentation

With the “General API documentation” and a response model documentation in place, we can move on and take a look at an endpoint documentation. For illustration purposes, we’ll document the GET /api/todos/:id endpoint. To do so, we must decorate the corresponding handler get_by_id (located in src/handlers/todo.rs) with the #[utoipa::path] attribute macro.

The #[utoipa::path] macro has an extensive API, allowing you to tailor all aspects of the endpoint-specific documentation. Take a minute to familiarize yourself with the macro and its capabilities :

#[utoipa::path(
    get,
  path = "/api/todos/{id}",
  tags = ["todos"],
  description = "Retrieve a ToDo-item using its identifier",
  params(
    ("id" = Uuid, Path, description = "ToDo identifier")
  ),
  responses(
    (status = 200, description = "Desired ToDo-item", body = ToDoModel),
    (status = 400, description = "Bad Request"),
    (status = 404, description = "Desired ToDo-item was not found"),
    (status = 500, description = "Internal Server Error")
    )
)]
pub(crate) fn get_by_id(_req: Request, p: Params) -> Result<impl IntoResponse> {
 // ...
}

Note that in contrast to the Spin HTTP router, utoipa expects route parameters to be specified using curly braces.

Exposing The OpenAPI Description

To expose the OpenAPI description, we first have to add another GET endpoint to the Spin application. To do so, use router.get in the entry point function (located in src/lib.rs):


#[http_component]
fn handle_spin_todo_api(req: Request) -> anyhow::Result<impl IntoResponse> {
    let mut router = Router::default();
    //...
    router.get("/docs/openapi-description.json", handlers::docs::get_openapi_description);
    //...
    Ok(router.handle(req))
}

Next, we have to add the actual handler in src/handlers/docs.rs and use our custom OpenApi struct:

use spin_sdk::http::{IntoResponse, Params, Request, ResponseBuilder};

pub fn get_openapi_description(_req: Request, _: Params) -> anyhow::Result<impl IntoResponse> {
    let openapi_description = OpenApiDocs::openapi();

    Ok(ResponseBuilder::new(200)
        .header("content-type", "application/json")
        .body(openapi_description.to_pretty_json()?)
        .build())
}

With the handler in place, let’s compile Spin application and test the new endpoint on our local machine:

# Compile the Spin application
spin build

# Run the Spin application
spin up

From within a new terminal instance, use a tool like curl and send a GET request to the new endpoint at http://localhost:3000/docs/openapi-description.json. You should see the Spin application responding with the prettified OpenAPI Description as JSON.

The OpenAPI Description could also be exposed as YAML file. To do so, use the optional yaml feature from the utoipa crate.

Adding OpenAPI Documentation UI

With the machine-readable OpenAPI Description in place, we want to go one step further and make our Spin application serve an OpenAPI Documentation UI. With utoipa, you can choose from different OpenAPI Documentation UIs, including:

Swagger UI using the utoipa-swagger-ui crate
Redoc using the utoipa-redoc crate
RapiDoc using the utoipa-rapidoc crate

Follow these steps to add good old Swagger UI to the Spin application:

Add utoipa-swagger-ui as a dependency (cargo add utoipa-swagger-ui)
Register a new route after the OpenAPI Description route:

#[http_component]
fn handle_spin_todo_api(req: Request) -> anyhow::Result<impl IntoResponse> {
   let mut router = Router::default();
   // ...
   router.get("/docs/openapi-description.json", handlers::docs::get_openapi_description);
   router.get("/docs/*", handlers::docs::render_openapi_docs_ui);
   Ok(router.handle(req))
}

Add a new handler to src/handlers/docs.rs which will examine the request path and render the Swagger UI for all requests not targeting the OpenAPI Description:

use std::sync::Arc;

pub fn render_openapi_docs_ui(req: Request, _p: Params) -> anyhow::Result<impl IntoResponse> {
    let mut path = req
       .header("spin-path-info")
       .expect("spin-path-info is not present")
       .as_str()
       .unwrap_or("/")
       .to_string();

    path = path.replace("/docs/", "");

    let config = Arc::new(utoipa_swagger_ui::Config::from("openapi-description.json"));

    Ok(match utoipa_swagger_ui::serve(path.as_ref(), config) {
        Ok(swagger_file) => swagger_file
            .map(|file| {
                ResponseBuilder::new(200)
                    .header("content-type", file.content_type)
                    .body(file.bytes.to_vec())
                    .build()
            })
            .unwrap_or_else(|| Response::new(404, "Not Found")),
        Err(_) => Response::new(500, "Internal Server Error"),
    })
}

Compile the Spin application and run it again on your development machine(spin build && spin up). Once compilation has finished and Spin CLI has spawned the listener on port 3000, browse http://localhost:3000/docs/ which should render Swagger UI and have the OpenAPI Description already loaded for you (as shown in the following figure):

Customizing OpenAPI Description

Although we provided plenty of information about the ToDo-API, we now want to go one step further and customize the OpenAPI Description based on incoming request circumstances.

We are going to extend the OpenAPI Description by adding a different Server depending on the host that is serving the documentation. This allows us to have a Development Server specified in the OpenAPI Description if we run the application on our local machine using spin up.

However, if we deploy the application to a remote runtime - such as Fermyon Wasm Functions - we want the Production Server to be specified in the OpenAPI Description document.

This simple example illustrates how you could customize the OpenAPI Description document before serving it over HTTP.

Customizations in utoipa are either achieved by adding custom Modifiers (custom structs that implement the Modify trait) or by mutating our instance of OpenApiDocs before sending it as an HTTP response body.

We’ll use the latter approach for adding a different server based on incoming request headers. To achieve this, update the get_openapi_description handler (in src/handlers/docs.rs) as shown here:

use utoipa::ServerBuilder;
use url::Url;

pub fn get_openapi_description(req: Request, _: Params) -> anyhow::Result<impl IntoResponse> {
    let mut openapi_description = OpenApiDocs::openapi();
    let (url, description) = get_server_info(&req);
    openapi_description.servers = Some(vec![
        ServerBuilder::new()
            .url(url)
            .description(Some(description))
            .build(),
    ]);

    Ok(ResponseBuilder::new(200)
        .header("content-type", "application/json")
        .body(openapi_description.to_pretty_json()?)
        .build())
}

fn get_server_info(req: &Request) -> (String, String) {
    match is_local_spin_runtime(&req) {
        true => {
            let full_url = req
                .header("spin-full-url")
                .expect("spin-full-url should be set when running api with spin CLI")
                .as_str()
                .expect("spin-full-url shall not be empty when running api with spin");

            let u = Url::parse(full_url).expect("spin-full-url should be a valid url");
            (
                format!(
                    "{}://{}/",
                    u.scheme(),
                    format!(
                        "{}:{}",
                        u.host_str().expect("spin-full-url should have host"),
                        u.port().expect("spin-full-url should have port")
                    )
                ),
                String::from("Local Development Server"),
            )
        }
        false => {
            let host = req
                .header("x-forwarded-host")
                .expect("x-forwarded-host should be set via FWF")
                .as_str()
                .expect("x-forwarded-host shall not be empty on FWF")
                .to_string();
            (
                format!("https://{host}/"),
                String::from("Production Server"),
            )
        }
    }
}

fn is_local_spin_runtime(req: &Request) -> bool {
    req.header("spin-client-addr").is_some()
}

With the customization in place, you can build and run the Spin application again. When browsing the Swagger UI again, you’ll recognize the Development Server being displayed:

Conclusion

By integrating the utoipa crate into Spin applications, we can keep our API implementation and documentation in perfect sync while reducing manual overhead. What starts with a handful of macros quickly results in a fully navigable OpenAPI Description, complete with Swagger UI, and even adaptable to runtime conditions. Whether you’re building for local development or deploying at scale, this approach ensures your APIs remain transparent, discoverable, and ready for both humans and machines to consume. Instead of treating documentation as an afterthought, you embed it directly into the lifecycle of your service. In other words, your documentation becomes as alive as your code—always current, always reliable, and always serving as the single source of truth for anyone who needs to understand or integrate with your API.

Running Cloudflare Workers Inside Spin Apps

Jasmine Mae — Thu, 14 Aug 2025 01:37:00 +0000

By: Matt Butcher

There are many kinds of serverless functions available. Cloudflare Workers are one popular form of function designed to run on the edge. But in many cases, you can compile, load, and execute Cloudflare Workers within Spin apps.

In this post, we’ll see one strategy that lets you embed an entire Cloudflare Worker inside of a Spin app, giving you the option to deploy the Worker to Cloudflare or deploy the entire app into any Spin-compatible runtime including SpinKube (that is, Kubernetes), Fermyon Cloud, or Akamai via Wasm Functions.

Getting Started

Before we dive into the procedural bits, its important to understand the primary difference between Cloudflare Workers and Spin apps. Cloudflare provides a JavaScript interpreter to run JS files. Specifically, it uses the V8 engine that powers the Chrome family of browsers. When Cloudflare runs a Worker, it loads the worker JS files into the interpreter and executes them.

In contrast, Spin executes WebAssembly binaries. Each time we run spin build, we are compiling a binary file that will be executed. With a JavaScript app, what we’re actually doing is embedding the SpiderMonkey (Mozilla) JS runtime, loading the scripts into the interpreter, and then compiling that whole thing to WebAssembly. So there are no .jsfiles in the package that we run. It’s all just WebAssembly byte codes.

The technique we use in this blog post calls out to the Workers as libraries. And that means that at spin build time, the worker will be compiled (alongside the rest of the Spin code) into that WebAssembly binary.

With the conceptual details out of the way, it’s time to dive into the code. We are assusme the installation of both Spin and NPM. That should be all you need to get going.

We’ll first create a Spin JavaScript app. Then, inside that app, we’ll create a Cloudflare Worker. We’ll verify that we can run that Worker locally, and then we’ll wire up Spin to route traffic to that worker. When we build the Spin app, we’ll have a single Wasm artifact that contains the Spin router and the Worker all in one.

Creating a Spin App

There is nothing special about creating a Spin app that will call out to a Cloudflare worker. We can follow the standard process:

$ spin new -t http-js --accept-defaults spin-worker

The command above will silently create a new spin-worker/ directory and add all of the necessary Spin files.

At this point, we can cd into that directory and run spin build to validate that the project can build.

$ cd spin-worker && spin build                     
Building component spin-worker with `npm install`

...

Component successfully written.
Finished building all Spin components

By starting a server and using curl to send a request, we can verify the output of our new app. In one terminal, run spin up to start the server. In another, access the server with curl:

$ curl localhost:3000
hello universe

Now we’re ready to create a new Worker inside of our Spin app.

Create a Worker

The official Cloudflare guide describes how to get started with workers. We’ll follow the same process.

Still working inside of the spin-worker directory, let’s create a new Cloudflare Worker called cf-worker.

$ npm create cloudflare@latest -- cf-worker

This will kick of a series of prompts. You should answer:

Category: Hello World example
Type: Worker only
Language: JavaScript
Git: No
Deploy your application: No

At this point, you should have a new subdirectory inside of spin-worker called cf-worker.

Just to validate that this is a real worker and can be executed, we can run Wrangler:

$ cd cf-worker && npx wrangler dev

The above will start a server on localhost:8787 (convenient, since it does not clash with Spin’s use of port 3000). Using curl in another terminal, we can see the result:

$ curl localhost:8787                                                                                                                                            
Hello World!

Let’s do a quick modification of the Worker so that we’ll be able to easily tell later that the worker is indeed being executed. In spin-worker/cf-worker/src/index.js, let’s edit the code to look like this:

export default {
    async fetch(request, env, ctx) {
        return new Response('Hello from a worker');
    },
};

We’ve updated the response to say Hello from a worker instead of Hello World!. Let’s rebuild and test by running that Wrangler command again:

$ npx wrangler dev

And now we get the following output from curl:

$ curl localhost:8787
Hello from a worker

We’re ready to edit our Spin app now to call this worker.

Calling the Worker from Spin

Let’s work on the Spin JavaScript code in spin-worker/src/index.js. First off, let’s do the simple thing and change the default Hello universe message to something clearer:

import { AutoRouter } from 'itty-router';

let router = AutoRouter();

router
    .get("/", () => new Response("Hello from Spin"))

addEventListener('fetch', async (event) => {
    event.respondWith(router.fetch(event.request));
});

We can run our Spin app with spin build --up, and then use curl to see the output:

$ curl localhost:3000 
Hello from Spin

Note that we’re using a different URL than we were when testing the Worker. We’re on port 3000 instead of 8787. When we hit the default route (/), we get the Hello from Spin message.

With a couple of modifications to our code, we can create a second route, called /worker that executes the worker and returns the result. Once more, editing the spin-worker/src/index.js file, we will add a few lines.

import { AutoRouter } from 'itty-router';
import Worker from '../cf-worker/src/index'

let router = AutoRouter();

router
    .get("/", () => new Response("Hello from Spin"))
    // When a client requests /worker, run the cf-worker function
    .get("/worker", Worker.fetch)

addEventListener('fetch', async (event) => {
    event.respondWith(router.fetch(event.request));
});

There are two important bits above.

First, we imported Worker from ../cf-workers/src/index. This line imports everything exported out of the worker. In our Worker code, we declared only one function, fetch. So by importing this way, we can now execute that function using Worker.fetch.

Then, in the router, we add a new route, /worker that, when called, will run Worker.fetch.

Now we can rebuild our Spin app and test it again using spin build --up. This time, we can run curl twice to verify that we can hit the main route and get Hello from Spin and then hit /worker and get Hello from a worker:

$ curl localhost:3000
Hello from Spin
$ curl localhost:3000/worker
Hello from a worker

And that’s the basics for how to call a Worker from within a Spin app.

Deploying a Worker to a Spin runtime

So far, we have run everything locally. It is easy to run this Spin-wrapped Worker on SpinKube (Kubernetes), Fermyon Cloud, Azure AKS, Rancher Desktop, and other places. For this example, we’re going to deploy the Spin app to Akamai using Fermyon Wasm Functions.

To do this, I will use the Spin Akamai plugin.

From inside of the spin-worker directory, we just use the spin aka deploy command:

$ spin aka deploy
App 'spin-worker' initialized successfully.
Waiting for application to be ready... ready

View application:   
https://f1f1b106-edea-4b45-85c1-38de0c06aa2b.aka.fermyon.tech/

And with that, I can now access my application once more using curl:

$ curl https://f1f1b106-edea-4b45-85c1-38de0c06aa2b.aka.fermyon.tech/       
Hello from Spin
$ curl https://f1f1b106-edea-4b45-85c1-38de0c06aa2b.aka.fermyon.tech/worker 
Hello from a worker

For directions on deploying to other environments, see the Spin Deployment Options documentation.

Next Steps

While many Cloudflare Workers can be run as easily as we showed above, there are a number of APIs that do not match between Workers and Spin apps. In a later post, we’ll cover how to write a more sophisticated app that can select resources like key value storage based on the runtime. With some careful code building, you can continue to manage one code base that combines both Spin and Workers.

Supercharging Spin Applications with Wizer

Jasmine Mae — Thu, 14 Aug 2025 01:16:26 +0000

By: Thorsten Hans

In today’s world, the quest for ultra-fast, low-latency applications is relentless. As the demand for real-time user experiences grows, optimizing serverless applications for runtime performance is not just desirable, but essential. Enter Wizer - the WebAssembly pre-initializer that is redefining the way we build and deploy lightning-fast workloads. In this post, we’ll explore how Wizer can be leveraged to compile data directly into Spin applications, with a hands-on use-case: delivering geo location lookup from a client’s IP address.

Our stack? We use Rust for implementing the Spin application, and we’ll deploy it to Fermyon Wasm Functions — the world’s fastest serverless compute platform—running on Akamai Cloud, the planet’s largest and speediest network.

Why Wizer?

Traditional serverless and microservice architectures often grapple with the classic cold-start problem and data loading overheads. Thanks to WebAssembly’s inherent speed and the ultra-efficient, high-density runtime powering Fermyon Wasm Functions, the typical cold start dilemma simply doesn’t exist in Fermyon Wasm Functions. Applications launch instantly, making real-time responsiveness the norm.

However, when your workloads rely on external data stores, you inevitably introduce latency—every remote fetch or database query adds precious milliseconds to your compute duration and undermines that hard-won performance edge.

Traditional serverless and microservice architectures have long struggled with these data access delays. Even as Wasm shaves execution time to the bare minimum, each round trip to a database can erode the benefits of instant startup. This emphasizes the need for new approaches to data handling when striving for truly lightning-fast applications.

That’s where Wizer shines:

Pre-initialized State: Wizer allows you to snapshot your application state—including loaded data structures—at build time. When your Wasm module gets instantiated, you’re already primed for action.
No External Dependency
No Latency: By baking data directly into the Wasm binary, your workload can respond to requests in record time.

Taking into context that Spin apps running on Fermyon Wasm Functions are distributed around the globe and incoming requests are routed to the closest data center, integrating data into the application binary is even more important. In a globally distributed setup like this, relying on a non-globally distributed external service (e.g., a hosted database or blob storage) will have a dramatic impact for a huge fraction of users, as their requests may travel across the globe for querying necessary data from the external service.

Example Use-Case: Lightning-Fast GeoIP Lookup

Imagine needing to determine a user’s country, city, or region based solely on their IP address. This is a common requirement for content localization, regulatory compliance, analytics, and more. The challenge? Most IP geolocation databases, like MaxMind’s GeoLite2, are massive and expensive to parse at runtime.

What if you could bake the entire geolocation database directly into your application binary, and serve geo lookups in just a few milliseconds—no database connections, no cold data fetches? With Spin and Wizer, you can!

Integrating Data Into a Spin Application

You can find the entire source code of the GeoIP-Lookup sample over on GitHub at fermyon/fwf-examples/tree/main/samples/geo-ip. We followed four steps for integrating the database into the application binary with Wizer:

We downloaded a database compatible with the maxminddb crate and place it in the geoip-static-db directory of the Spin application
We defined an init function that loads the database and stores it in a static variable
We ran wizer to pre-initialize the Wasm module. Wizer executes the init function at build-time, snapshots the in-memory state (including the loaded geo database), and emits a pre-initialized Wasm module.
We deployed the resulting - pre-initialized - Spin application to Fermyon Wasm Functions

Under the Hood: Browsing the source code

Let’s go one layer deeper and look at the actual source code, invoked by Wizer and required to store the actual data in the Wasm binary. We’re using the maxminddb crate for Rust allowing us to load the database and execute queries against it.

The database itself is held in memory using a static variable:

use maxminddbReader;
use std::sync::OnceLock;

static DB: OnceLock<Reader<Vec<u8>>> = OnceLock::new();

The exported init function (which will be invoked by wizer at build-time, is responsible for loading the MaxMind database from the disk and stores it in our static DB variable:

#[export_name = "wizer.initialize"]
pub extern "C" fn init() {
    let mut args = String::new();
    std::io::stdin()
        .read_line(&mut args)
        .expect("failed to read stdin");
    let args = args.trim().split_whitespace().collect::<Vec<_>>();

    match args[..] {
        [mmdb_path] => {
            println!("Loading maxminddb file from {mmdb_path}");
            let db = maxminddb::Reader::open_readfile(mmdb_path)
                .expect("Failed to open {mmdb_path}");
            DB.set(db).expect("Failed to set DB");
        }
        _ => {
            panic!("Expected one argument: <mmdb_path>");
        }
    }
}

The geoip-static-db Wasm component encapsulates data and lookup logic from the HTTP API, and exposes the lookup interface - as defined in WIT:

package fermyon:geoip;

interface lookup {
    lookup: func(ip: string) -> result<location, error>;
    record location {
        country: string,
        city: string,
        latitude: f64,
        longitude: f64,
    }

    enum error {
        invalid-ip,
        not-found,
        internal,
    }
}

world geoip {
    export lookup;
}

The implementation of the lookup function is straightforward thanks to the maxminddb crate. The provided IP address is parsed into the IpAddr structure (std::net::IpAddr), which we can use to query the city, country, longitude and latitude and create a response according to the location record defined in WIT:

fn lookup(ip: String) -> Result<Location, Error> {
  let db = DB.get().ok_or(Error::Internal)?;
  let ip_addr: IpAddr = ip.parse().map_err(|_| Error::InvalidIp)?;
  let record: geoip2::City = db
    .lookup(ip_addr)
    .map_err(|e| {
      eprintln!("Error looking up IP: {e}");
      Error::Internal
     })?.ok_or(Error::NotFound)?;

  let city = record
    .city
    .and_then(|city| city.names.and_then(|names| names.get("en").cloned()))
    .filter(|name| !name.is_empty())
    .unwrap_or_else(|| "Unknown");

  let country = record
    .country
    .and_then(|country| country.names.and_then(|names| names.get("en").cloned()))
    .filter(|name| !name.is_empty())
    .unwrap_or_else(|| "Unknown");

  let longitude = record
    .location
    .as_ref()
    .and_then(|loc| loc.longitude)
    .unwrap_or(0.0);

  let latitude = record.location.and_then(|loc| loc.latitude).unwrap_or(0.0);

  Ok(Location {
    city: city.to_string(),
    country: country.to_string(),
    longitude,
    latitude,
  })
}

With the lookup interface implemented, the HTTP API component can simply grab the client’s IP address from the true-client-ip request header and call the lookup function:

#[http_component]
fn handle_hello_geoip(req: Request) -> anyhow::Result<impl IntoResponse> {
    let ip = req.header("true-client-ip")
        .expect("true-client-ip")
        .as_str()
        .unwrap();

    let res = fermyon::geoip::lookup::lookup(ip)?;

    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body(format!(
            "IP: {}\\nCountry: {}\\nCity: {}\\nLatitude: {}\\nLongitude: {}",
            ip, res.country, res.city, res.latitude, res.longitude
        ))
        .build())
}

Building and Testing the Spin Application

For compiling the source code to Wasm and to perform the pre-initialization, the following tools must be installed on your machine

Rust - Including thewasm32-wasip1 target
wizer - You can install Wizer using cargo install wizer --all-features
wget - For downloading a MaxMindDB compliant database
wasm-opt (optional) - You can install wasm-opt using cargo install wasm-opt

# Download a MaxMindDB compliant sample database from <https://github.com/P3TERX/GeoLite.mmdb>
wget <https://git.io/GeoLite2-City.mmdb>

# Move the database to the desired location
mv GeoLite2-City.mmdb geoip-static-db/geoip.mmdb

# Run the build script to
# - Compile the Rust source code
# - Execute Wizer
# - Optimize Wasm binary file size if wasm-opt is installed
make build

Once application compilation has finished, you can run the app on your local machine using spin up. When sending requests to app, ensure to provide the desired IP address using the true-client-ip HTTP header:

curl -H 'true-client-ip:46.165.131.203' localhost:3000

IP: 46.165.131.203
Country: Germany
City: Siebeldingen
Latitude: 49.2059
Longitude: 8.0524

Deploying to Fermyon Wasm Functions

For deploying the application to Fermyon Wasm Functions, you must be authenticated. (spin aka login). Once authenticated, deployment is as easy as executing the spin aka deploy command and waiting for the app to be deployed across all service regions:

spin aka deploy --create-name geoip-lookup --no-confirm

Workspace linked to app geoip-lookup
Waiting for app to be ready... ready

App Routes:
- geoip-example: <https://86d3582b-a318-431f-bc7a-e26a2350137b.aka.fermyon.tech> (wildcard)

Once app deployment has been finished you can start sending requests to the generated endpoint and see how fast our Spin app is able to locate you, based on your IP address:

curl <https://86d3582b-a318-431f-bc7a-e26a2350137b.aka.fermyon.tech>
IP: 46.165.131.203
Country: Germany
City: Siebeldingen
Latitude: 49.2059
Longitude: 8.0524

time curl <https://86d3582b-a318-431f-bc7a-e26a2350137b.aka.fermyon.tech>
IP: 46.165.131.203
Country: Germany
City: Siebeldingen
Latitude: 49.2059
Longitude: 8.0524
curl <https://86d3582b-a318-431f-bc7a-e26a2350137b.aka.fermyon.tech>  0.01s user 0.01s system 4% cpu 0.083 total

See the output from time curl ... indicating that the end-to-end execution time is as little as 83ms! But we can get more insights. Just sent another curl request to the app and provide the -i flag to print all response headers to stdout:

curl -i <https://86d3582b-a318-431f-bc7a-e26a2350137b.aka.fermyon.tech>
HTTP/1.1 200 OK
Content-Type: text/plain
x-envoy-upstream-service-time: 1
Server: envoy
Date: Fri, 04 Jul 2025 11:32:33 GMT
Content-Length: 90
Connection: keep-alive

IP: 46.165.131.203
Country: Germany
City: Siebeldingen
Latitude: 49.2059
Longitude: 8.0524

Find the x-envoy-upstream-service-time HTTP header, indicating the pure compute time within Fermyon Wasm Functions is below 1ms.

Conclusion

By combining the Wasm pre-initialization with Wizer, Spin and the incredible speed provided by Fermyon Wasm Functions, you can deliver serverless applications with performance once thought impossible. Whether you’re building geo-aware content, compliance solutions, or real-time request processing, this stack lets you optimize for pure speed.

Building a GraphQL API with Fermyon Wasm Functions

Jasmine Mae — Mon, 28 Jul 2025 19:19:30 +0000

By: MacKenzie Adam

GraphQL has revolutionized how we think about APIs, offering developers precise control over data fetching and reducing over-fetching issues common with REST APIs. When combined with the lightning-fast startup times and efficiency of WebAssembly, GraphQL becomes even more powerful for serverless applications.

In this blog, we’ll walk through building a complete GraphQL client using Fermyon Wasm Functions that queries GitHub’s GraphQL API to fetch and report repository stargazer information. By the end, you’ll have a globally distributed, fully functional serverless application that demonstrates the power of combining type-safe GraphQL queries with WebAssembly.

What We’re Building

We’ll create a serverless GraphQL client as a Spin application that:

Uses Rust’s type-safe GraphQL client generation
Demonstrates secure API token handling in serverless environments
Queries GitHub’s GraphQL API for repository stargazer counts
Renders results as a simple HTML page
Runs on the Fermyon Wasm Functions platform with sub-millisecond cold starts

Prerequisites

Before we dive in, make sure you have:

Spin CLI installed
Rust toolchain with wasm32-wasip1 target
A GitHub personal access token with repository read permissions
Basic familiarity with GraphQL and Rust
Access to either Fermyon Wasm Functions platform (used in this tutorial) or Fermyon Cloud

To deploy this on Fermyon Wasm Functions, you must request access to the service. If you do not have global distribution requirements, you can follow along using Fermyon Cloud instead which offers a free developer tier.

Setting Up Your Development Environment

First, let’s clone the sample which is available in the Fermyon Wasm Functions example repository.

git clone https://github.com/fermyon/fwf-examples.git
cd samples/graphql-stargazer

A quick check of the folder reveals a typical Spin application directory structure with a source code directory, spin.toml (application manifest), and cargo.toml.

ls
Cargo.lock  Cargo.toml  README.md   spin.toml   src     target

Understanding the GraphQL Schema and Query

Our application uses GitHub’s public GraphQL API. In this sample, for the sake of simplicity, we’re only interested in extracting the stargazers count for a particular repository.

For our stargazer query, we create a focused query file src/query_1.graphql:

query RepoView($owner: String!, $name: String!) {
  repository(owner: $owner, name: $name) {
    homepageUrl
    stargazers {
      totalCount
    }
  }
}

This query accepts two variables (repository owner and name) and returns the total count of stargazers along with the homepage URL.

Implementing the GraphQL Client

Let’s build our implementation step by step, focusing on the key concepts that make this approach powerful. If you’re following along locally, navigate to src/lib.rs as we dive into the application logic.

Type-Safe GraphQL Code Generation

The magic of our implementation starts with Rust’s type-safe GraphQL code generation. Using the graphql_client crate, we can generate compile-time validated Rust code from our GraphQL schema and queries:

use graphql_client::GraphQLQuery;

#[derive(GraphQLQuery)]
#[graphql(
    schema_path = "src/schema.graphql",
    query_path = "src/query_1.graphql",
    response_derives = "Debug"
)]
struct RepoView;

This single derive macro does a lot of work behind the scenes:

Generates type-safe Rust structs from your GraphQL schema
Creates query builder methods like RepoView::build_query()
Provides compile-time validation that your queries match the schema
Handles all serialization/deserialization automatically

The generated code creates a repo_view::Variables struct for query parameters and repo_view::ResponseData for the response, ensuring you can never send malformed queries or access non-existent fields.

Secure Token Management with Spin Variables

Instead of hardcoding API tokens, we use Spin’s secure variable system which you can see in this snippet from lib.rs here:

let github_api_token = spin_sdk::variables::get("gh_api_token")
    .expect("Missing gh_api_token variable");

We’ll review in more detail how this variable is set later on. By using this approach, we ensure tokens are:

Never stored in source code
Injected securely at runtime
Easy to rotate without code changes

Building and Sending the GraphQL Request

Once we have our query variables, building the request is straightforward:

// Create variables for our GraphQL query using the generated types
let variables = repo_view::Variables {
    owner: owner.to_string(),
    name: name.to_string(),
};

// Build the GraphQL query structure with our variables
let body = RepoView::build_query(variables);
// Serialize the query to JSON for the HTTP request
let body = serde_json::to_string(&body).unwrap();

// Construct the HTTP POST request to GitHub's GraphQL endpoint
let outgoing = Request::post("https://api.github.com/graphql", body)
    .header("user-agent", "graphql-rust")         // GitHub requires a user-agent
    .header("content-type", "application/json")   // GraphQL queries are sent as JSON
    .header("Authorization", format!("Bearer {}", github_api_token))  // API authentication
    .build();

// Send the request and await the response
let res: Response = send(outgoing).await?;

The type-safe build_query() method ensures we’re sending exactly the right GraphQL query structure to GitHub’s API.

Processing the GraphQL Response

The response handling showcases the utility of generated types:

// Parse the GraphQL response into our generated type-safe structs
let response: graphql_client::Response<repo_view::ResponseData> =
    serde_json::from_slice(res.body()).unwrap();
// Extract the actual data from the GraphQL response wrapper
let response_data = response.data.expect("missing response data");

// Navigate the response with complete type safety
// The compiler ensures these fields exist and have the right types
let stars = response_data
    .repository
    .as_ref()  // Handle the case where repository might be null (not found)
    .map(|repo| repo.stargazers.total_count);

Notice how we can navigate the response with complete type safety: response_data.repository.stargazers.total_count is validated at compile time to match our GraphQL schema.

URL Parsing and Error Handling

Our application expects URLs like /fermyon/finicky-whiskers and extracts the repository information:

fn parse_repo_name(repo_name: &str) -> Result<(&str, &str), anyhow::Error> {
    // Split the path on '/' and skip the first empty element
    // For "/fermyon/finicky-whiskers", this gives us ["", "fermyon", "finicky-whiskers"]
    let mut parts = repo_name.split('/').skip(1);

    // Extract owner and repository name, ensuring both exist
    match (parts.next(), parts.next()) {
        (Some(owner), Some(name)) => Ok((owner, name)),
        _ => Err(format_err!(
            "wrong format for the repository name param (we expect something like spinframework/spin)"
        ))
    }
}

Configuration with `spin.toml`

Now that we’ve completed our application logic, let’s take a look at how our application’s capabilities and constraints are expressed in the application manifest (spin.toml). Our spin.toml file configures the application with proper security constraints. Here we have a single component application that is invoked with an HTTP trigger. This component has the capability to make an outbound HTTP call and can access a variable called gh_api_token, which we used above to make calls to GitHub’s public API. This is the value that get passed into our lib.rsfile.

spin_manifest_version = 2

[application]
name = "graphql"
version = "0.1.0"
authors = ["Till Schneidereit <till@tillschneidereit.net>"]
description = "GraphQL experiments"

[variables]
gh_api_token = { secret = true, required = true }

[[trigger.http]]
route = "/..."
component = "graphql"

[component.graphql]
source = "target/wasm32-wasip1/release/graphql.wasm"
allowed_outbound_hosts = ["https://api.github.com"]
variables = { gh_api_token = "{{ gh_api_token }}" }
[component.graphql.build]
command = "cargo build --target wasm32-wasip1 --release"
watch = ["src/**/*.rs", "Cargo.toml"]

Security Features

Secret variables: The GitHub token is marked as secret = true
Outbound host restrictions: Only https://api.github.com is allowed
Secure by default: WebAssembly’s sandbox model provides additional isolation such as preventing access to the filesystem unless explicitly granted to the Spin app

Building and Testing Locally

To run the application locally:

# Install the WebAssembly target if you haven't already
rustup target add wasm32-wasip1

# Build the application
spin build

# Run with your GitHub token
SPIN_VARIABLE_GH_API_TOKEN=[your-token-here] spin up

Note that you must set the variable name exactly as above to pass in the variable when running a Spin app locally.

Now you can test it by visiting URLs that follow this format, corresponding to the desired GitHub organization and repo:

http://localhost:3000/gh-org/gh-repo

curl localhost:3000/fermyon/finicky-whiskers

Each will show you the stargazer count for that repository!

Deploying to Fermyon Wasm Functions

Deployment is straightforward with Fermyon Wasm Functions. With one simple command, your application will be globally distributed:

# Log into Fermyon Wasm Functions if you haven't already
spin aka login

# Deploy with your GitHub token
spin aka deploy --variable gh_api_token=[your-token-here]

The deployment will provide you with a unique URL where your GraphQL client is running in production.

<...>                      
App Routes:
- graphql: https://87f9c916-331c-4a44-b7ad-d2a8331185ff.aka.fermyon.tech (wildcard)

If you’re following along using Fermyon Cloud, you can find steps on how to deploy here.

Conclusion

Building GraphQL clients with Fermyon Wasm Functions combines the precision of GraphQL with the performance benefits of WebAssembly. This approach is particularly powerful for:

APIs requiring type safety and compile-time validation
Applications with unpredictable traffic patterns
Microservices architectures requiring fast startup times
Teams wanting to leverage Rust’s ecosystem for API clients

The serverless nature of Wasm Functions ensures your applications run fast and secure on Fermyon Wasm Functions.

Resources and Further Reading:

Running Serverless Wasm Functions on the Edge with k3s and SpinKube

Jasmine Mae — Fri, 25 Jul 2025 03:43:28 +0000

By: Matt Butcher

Originally presented at SUSECON 25 by Matt Butcher, CEO of Fermyon Technologies. Watch the full presentation on YouTube.

The cloud computing landscape has evolved through distinct phases: from one-to-one hardware-OS relationships, to virtual machines enabling multiple operating systems per machine, to containers providing lightweight process isolation. Today, we’re witnessing the emergence of a fourth paradigm: WebAssembly (Wasm) in the cloud — and it’s perfectly suited for serverless workloads on Kubernetes.

Traditional Serverless

While containers revolutionized how we package and deploy long-running services like NGINX, PostgreSQL, and API servers, they fall short for serverless workloads. Both virtual machines and containers suffer from the same fundamental limitation: startup times of 12+ seconds, sometimes stretching into minutes.

This latency makes true serverless difficult to achieve. Current solutions like AWS Lambda and Azure Functions work around this by maintaining huge queues of pre-warmed virtual machines — hardly an efficient approach for handling event-driven workloads where requests should trigger handlers that start, execute, and shut down quickly.

Why WebAssembly is Perfect for Serverless

WebAssembly wasn’t originally designed for the cloud, but its browser-oriented features make it ideal for serverless functions:

1. Security First
Web browsers are arguably our most trusted software — we visit countless websites daily without worrying about system crashes. WebAssembly’s sandbox environment is even more secure than JavaScript’s, using a capability-based system where you can selectively enable or disable features. This is perfect for multi-tenant cloud environments where isolation is critical.

2. Lightning-Fast Cold Starts
While Google’s research shows user attention begins to wane after 100 milliseconds of inactivity, WebAssembly was designed for instant execution. In our testing, we’ve achieved 0.5 millisecond cold start times — compared to AWS Lambda’s 100-500 millisecond cold starts. This enables running thousands of applications per node simultaneously.

3. Write Once, Run Anywhere
Unlike Docker images that require separate builds for ARM and Intel architectures, WebAssembly binaries are truly portable. The same binary runs across any operating system and architecture — including GPUs for AI inferencing workloads.

4. Language Agnostic
About 23 of the top 25 programming languages (according to RedMonk) support WebAssembly compilation. Whether you’re writing in Rust, JavaScript, Python, Ruby, or Go, everything compiles to the same binary format.

Introducing Spin and SpinKube

We’ve built two complementary tools to bring WebAssembly into Kubernetes:

Spin: The developer framework for building serverless functions with built-in bindings for key-value storage, relational databases, AI inferencing, and more
SpinKube: The Kubernetes operator that runs Spin applications natively in your cluster

Both Spin and SpinKube are now part of the Cloud Native Computing Foundation (CNCF), officially accepted in January 2025. This ensures long-term sustainability and community-driven development.

How SpinKube Integrates with Kubernetes

SpinKube isn’t just another container runtime — it’s fully integrated into the Kubernetes ecosystem. When you deploy a Spin application:

The SpinKube operator listens for SpinApp resources
Converts them to standard Kubernetes Deployments
Creates ReplicaSets and Pods as usual
Integrates with containerd via a WebAssembly shim
Executes Wasm binaries instead of containers

This means all your existing Kubernetes tools, volumes, secrets, config maps, and SSL certificates work seamlessly with WebAssembly workloads.

Getting Started with Rancher Desktop

The easiest way to try SpinKube is with Rancher Desktop, which includes built-in support:

Enable containerd: In Preferences → Container Engine, select containerd and enable “WebAssembly (wasm) support”
Install SpinKube: In Preferences → Kubernetes, check “Install Spin operator”
Restart: Let Rancher Desktop restart to apply changes

Building Your First Spin Application

Here’s how to create and deploy a simple serverless function:

1. Create a New Project

spin new
# Select template: http-ts (TypeScript HTTP handler)
# Project name: hello-kubecon
# Description: Hello KubeCon demo
# HTTP path: /... (handles all routes under /)

2. Build the Application

cd hello-kubecon
spin build

This compiles your TypeScript into a WebAssembly binary ready for deployment.

3. Deploy to Kubernetes

# Push to OCI registry
spin registry push ttl.sh/hello-kubecon:1h

# Deploy to Kubernetes
spin kube deploy

4. Test Your Function

# Port forward to access locally
kubectl port-forward svc/hello-kubecon 8080:80

# Test the endpoint
curl localhost:8080

The Power of Integration

What makes this approach compelling is that SpinKube applications are first-class Kubernetes citizens:

# Standard Kubernetes commands work
kubectl get spinapp
kubectl get deployment
kubectl get pods
kubectl get services

# Delete the application
kubectl delete spinapp hello-kubecon

Performance Benefits

The performance characteristics of WebAssembly in Kubernetes are remarkable:

0.5ms cold start time vs. 100-500ms for traditional serverless
Thousands of concurrent functions per node
Efficient scaling up and down based on demand
Better resource utilization on both small embedded devices and large clusters

Next Steps

Ready to explore serverless WebAssembly on Kubernetes? Here’s how to get started:

Documentation: spinframework.dev
Source Code: github.com/spinframework/spin
Community: Join the CNCF Slack #spin and #spinkube channels
Try It: Download Rancher Desktop and follow the setup guide above

You can watch the full presentation on YouTube.

Serverless A2A with Spin

Jasmine Mae — Mon, 07 Jul 2025 17:09:03 +0000

By: Matt Butcher

In only a few short years, LLMs have gone from a niche technology to the heart of a new wave of AI applications. And even more recently, Model Context Protocol (MCP) has earned buzz by standardizing a way to expose tools to LLMs and reasoning agents. But exposing tools is only a small step in harnessing the power of AI agents. Google recently contributed a new open protocol to Linux Foundation. A2A (short for Agent-to-Agent opens new opportunities for building agentic systems. In this post we’ll see how easy it is to create Spin apps that implement the A2A protocol.

What is an Agent?

In AI parlance, an agent is a piece of code, typically backed by some form of AI, that performs tasks on behalf of a user. As an example, one could envision a travel agent that received a prompt (“Book me a flight and hotel in Chicago next week.”) and then acted on that prompt, returning a response (“Okay, I booked you the following flight and hotel…”). Sometimes agents are conversational. The simple example above would more likely be carried out over a conversational series (“Agent: What part of Chicago would you like to stay in?”, “User: River North or Downtown”). Sometimes they might return parseable data instead of human text. Or sometimes they might produce audio, images, or video.

While agents may do things on behalf of a user, it is not necessarily the case that an agent will directly interact with a user. For example, one recent trend has been to connect agents to GitHub repositories. An agent can perform an action when something in a GitHub repo changes (for example, when an issue is filed or a pull request is created). An agent may be able to complete its job without directly interacting with the GitHub repository owners.

Even more exciting, though, is agent-to-agent communication. In this case, one agent may leverage other agents it knows about in order to achieve a particular result. That’s where A2A comes in.

What is A2A?

A2A is a simple protocol for connecting agents. It has two main functions:

Agent discovery: Allow agents to discover each other
Agent interaction: Define how one agent can send messages to, and receive messages from, another agent

The protocol is based on JSON, JSON-RPC, HTTP, and SSE (Server Sent Events), all of which are broadly understood and utilized standards and techniques. This is good news; we can use existing libraries and tools to write our agents.

Let’s take a look at these two parts of the A2A spec.

Discovery with Agent Cards

Many existing Web standards perform discovery by the simplest possible means: Agree on a standard location and standard data format for a basic piece of information. For example, robots.txt files inform web crawlers of how to traverse a site’s content. A file named favicon.ico provides an icon for site. In both of these cases, humans and applications alike can assume both the location and data format for these files.

The A2A specification defines a similar technique for allowing agents to discover each other. A JSON formatted file at /.well-known/agent.json describes the available agent endpoints at a particular server and how those agents can be interacted with.

For this post, I wrote a simple A2A-style agent that uses Gemini to answer ethical questions using one of the major Western moral philosophies (deontology, virtue ethics, and utilitarianism). Here’s what that agent’s card looks like:

{
  "name": "The Digital Ethicist",
  "description": "This agent analyzes ethical questions based on philopsophical ethics frameworks such as utilitiarism, deontology, or virtue ethics.",
  "url": "http://localhost:41241/api",
  "provider": {
    "organization": "Technosophos"
  },
  "version": "0.1.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false
  },
  "defaultInputModes": [
    "text/plain"
  ],
  "defaultOutputModes": [
    "text/plain"
  ],
  "skill": [
    {
      "id": "ethics-utilitarian",
      "name": "Digitial Utilitarian",
      "description": "Address ethical problems and dilemmas using utilitarian approaches.",
      "tags": [
        "philosophy",
        "ethics",
        "reasoning",
        "morality",
        "moral philosophy",
        "utilitarianism",
        "hedonic calculus"
      ],
      "examples": [
        "Is it okay to cross a crosswalk against the light if there are no cars coming?"
      ]
    }
  ]
}

For the most part, the card format is so intuitive that we can read through the fields and understand the purpose. In a nutshell, though, the card describes what this endpoint can do, and exposes one or more skills. When a client issues a request against this A2A service, it can use the skill ID to inform the endpoint what specific task it is asking the agent to perform. In the example above, one skill is exposed: A utilitarian ethical reasoner. (Utilitarianism is a philosophical system of ethics that determines what is ethical based on how much pleasure or pain is caused by an action.)

Inter-agent Interaction with JSON-RPC

Thanks to the card, humans and agents (and even tools) can all understand what agents we have made available, and what they do. Thanks to the A2A interaction protocol, it is also clear how to interact with our agents.

The JSON-RPC 2.0 specification defines a remote procedure call (RPC) mechanism that defines how a client can request that a service run a function and return the result to the client. We won’t go into this protocol in any detail, but there is one thing specific to A2A that we should cover: The multiple modes of interaction.

The agent card can describe its capabilities. In the example above, there is a section that

"capabilities": {
  "streaming": false,
  "pushNotifications": false
},

speaking practically, it means that as we write our agents, we have different options for how to construct the interaction between two agents.

Asynchronous Sessions: Send a request, get a response that includes a session ID. For a follow-up message in the same context, send the session ID. This is a default feature. All A2A servers are expected to implement it.
Streamed Sessions: Open a stream and send a series of messages back and forth. This technique uses HTTP SSE (Server Sent Events) to keep a stream open and allow the server to initiate events. By setting the streaming capability to true, we can indicate that we support it.
Push Notifications: Send a request that includes a notification URL. When the agent is done processing the request, notify via the notification URL. This uses webhooks as a callback mechanism for an agent. We can indicate support for this in the agent card by setting the pushNotifications capability to true.

Note that the very simplest case, a one-shot question-and-answer, is just a simple use of asynchronous sessions. We’ll build one of those in the next section.

How do you choose which one to use in any given set of circumstances?

Streamed sessions use a long-running network connection to send multiple messages between the client and the server agent. In most cases, asynchronous sessions are better (and I’ll describe why in a moment). But one cases where streamed sessions works very well is when the client side of the communication is not another agent, but is a human who is impatient and wants to see at least the beginning of results as soon as they are available. You can envision the way that many AI-based chats stream back tokens to emulate a user typing on a keyboard.

Streamed sessions are less resource efficient because they consume network and compute resources on both the client and server even when one or both sides are just waiting. SSE logic adds more complexity to application code, and often do no good if the client-side is another agent or tool. There is no reason to keep a network connection open and compute resources allocated while waiting for a client agent to run returned data through its own model, or even contact other agents. This is wasteful in an expensive way.

A2A’s asynchronous mode is a better fit in most cases. In this case, a request is sent to the agent, which sends back a response and then closes the connection. If the client agent then needs to make a follow-up request, it opens a new connection and sends a new request. By sending the session ID provided by the server agent in the last interaction, the client clearly indicates that this is the continuation of an existing session rather than a new session. This mode fits better with the agent-to-agent modeling we’d expect, where a client agent would receive a response, process it through its own logic, and possibly (perhaps seconds, minutes, or even hours later) issue a follow-up request.

This points to an emerging trend. As agent-to-agent interactions become more popular, we will stop looking at sessions as short-lived (as they are in the human-to-agent chat apps today). Instead, they will have durations more like email exchanges, which may last months or longer, but be intermittent. Building with an asynchronous mode just makes more sense.

But there is another option that works really well if the task at hand will take the server agent longer than a couple of minutes. And that’s the push notification method. For example, generating videos or large images may take a non-trivial amount of time. And, again, if this agent-to-agent thing really takes off, it may take a long time for the server agent to find and talk to other agents that will help it complete its task. In these cases, supplying a callback webhook means the client- and server-side agents can disconnect (and free up network resources) while the server-side agents continues to work. Then the server-side agent can inform the client via webhook that the result is ready.

Now that we have a solid understanding of how A2A works, let’s take a look at an example.

The Virtual Ethicist Code

Our agent will take a situation and provide a recommended action based on one of a few prominent moral philosophies. We’ll be using Gemini’s reasoning LLM, and here is the prompt we will send it:

You are a utilitarian moral philosopher. Announce which moral framework you are using, and then answer the question.

We’ll be writing the agent as a Spin app. To get going, we’ll use spin new and then immediately do a spin build to fetch all the necessary dependencies and get us started. The entire code can be found here in GitHub.

Now we can edit the src/index.ts file. We’ll focus on just two key functions.

taskUtilitarian is the main task for our agent
doGeminiInference fulfills the task using Google’s Gemini

// The main task handler for each request
async function taskUtilitarian(id: string, params: any): Promise<Response> {

  // Get the question from the client's request
  let question = params.message.parts[0].text;

  // Create a task object that returns a one-shot inference
  let task = new Task();
  task.id = id;
  task.sessionId = generateSessionId();
  task.status = new TaskStatus();
  task.status.state = "completed";
  task.status.message = {
    role: "agent",
    parts: [
      {
        type: "text",
        // Ask the question to Gemini and wait for the answer
        text: await doGeminiInference(question),
      },
    ],
  };

  // Build the JSON-RPC response envelope
  let envelope = {
    jsonrpc: "2.0",
    id: id,
    result: task,
  };

  // Send the entire response back to the client
  let res = new Response(JSON.stringify(envelope));
  res.headers.set("content-type", "application/json");
  return res;
}

// Helper that uses Google Gemini to do the inference
async function doGeminiInference(question: string): Promise<string> {
  let inference = await gemini.models.generateContent({
    model: "gemini-2.0-flash",
    contents: `You are a utilitarian moral philosopher. Announce which moral framework you are using, and then answer the question.

    ${question}`,
  });
  return Promise.resolve(inference.text || "Some philosophers choose silence.");
}

The snippet above shows the main agent, which runs a task on behalf of the client and then returns the result. We’re using the Gemini 2.0 Flash model, which is fast and efficient, and does a good job of handling this type of request.

One really cool thing about A2A is that the details of how we do the inference are opaque to the end user. If we discovered that, say, LLaMa did a better job of answering ethical questions, we could swap all of this out without so much as inconveniencing clients. In a sense, this is part of what makes A2A a compelling technology: One agent can learn how to interact with another agent, but without needing detailed information about how that agent is getting its work done.

Where Should Agents Run?

The agent we built above is a Spin app. Spin applications can run in a variety of locations, from your local system to Kubernetes clusters to the Akamai edge. What makes the most sense?

If the results are cacheable, then put the application on the edge, as that will ensure that the agent runs as close as possible to the requesting client (be it another agent or a human).
If you are running your own models, run the app as close to your GPUs as possible. So, for example, if you are using Civo GPUs to host a model, run the code in Civo’s cloud. (And if you are running edge GPUs, like with Akamai Cloud GPUs, this gives you the edge advantage even for self-hosted models)
If you are using an AI service like Google Gemini, running as close to the user is likely a good move, since that will make use of the nearest GPU to the client. So once again, running at edge is best.

For the Gemini-based example above, I deployed to an Akamai endpoint, and then used Google’s demo A2A client to connect. Here’s what it looks like in action:

The response from the agent is detailed, providing a reason and then a “final verdict” for the prescribed action.

Conclusion

MCP is a protocol for exposing tools to agents. But A2A is different. Its purpose is to standardize a way for one agent to call to another agent. That requires two basic features: The ability to discover other agents, and the ability to interact with discovered agents. In A2A, the first is provided by JSON files in a simple agent card format. The second is provided via the existing JSON-RPC specification plus a few refinements for handling the longer interactions required by AI processing.

A2A is still lifting off, and it may be a little while before we see agents actually discovering and making use of other agents. But the foundation for this kind of interaction is laid by this new specification.

Unlocking Otel in WebAssembly - Wasm I/O 2025

Jasmine Mae — Thu, 03 Jul 2025 22:29:19 +0000

As WebAssembly continues its march into production environments, the need for robust observability becomes increasingly critical. At Wasm I/O 2025, Caleb gave an insightful talk on how OpenTelemetry is solving the observability puzzle for WebAssembly apps.

YouTube Recording: Unlocking Observability in WebAssembly with OpenTelemetry by Caleb Schoepp @ Wasm I/O 2025

The Challenge: Observing the Unobservable

WebAssembly’s sandboxed nature, whilst providing excellent security and portability, creates unique challenges for observability. Traditional monitoring approaches often fall short when dealing with the host-guest architecture that defines WebAssembly apps.

Caleb outlines three key places where telemetry can be collected in WebAssembly systems:

Host-Guest Telemetry - Observing interactions between the WebAssembly runtime and components
Inter-Guest Telemetry - Tracking communication between different WebAssembly components
Intra-Guest Telemetry - Emitting traces from within WebAssembly components themselves

Auto-Instrumentation: The Low-Hanging Fruit

One of WebAssembly’s superpowers is the ability to provide automatic instrumentation without much developer effort. Caleb shows this using Spin, the serverless WebAssembly framework for developing apps. He shows how a simple Rust component automatically generates rich tracing data.

Trace data includes:

HTTP request handling
Component execution spans
Host resource interactions (like key-value store operations)

This auto-instrumentation is cross-language and requires zero code changes - you simply get observability “for free” by running your components in an instrumented runtime.

Beyond Auto-Instrumentation: Custom Tracing

While auto-instrumentation provides valuable baseline visibility, production apps need custom tracing that reflects business logic and application-specific workflows. This is where OpenTelemetry’s standard APIs shine.

The challenge? Getting OpenTelemetry to work seamlessly within WebAssembly’s constrained environment.

Caleb demonstrates two approaches:

Approach 1: HTTP Exporter with WASI-HTTP

Using familiar OpenTelemetry SDKs with an HTTP exporter backed by WASI-HTTP. This approach feels familiar to developers but has limitations:

Difficult to compile OpenTelemetry libraries to WebAssembly
Can’t access parent trace context in non-HTTP components
Unable to properly associate host operations with guest spans

Approach 2: WASI-OTel Processor

A more sophisticated approach using a special processor backed by the new WASI-OTel proposal. This enables:

Proper parent-child relationships between host and guest spans
Full trace context propagation across the host-guest boundary
Seamless integration of host operations into guest-initiated traces

The WASI-OTel Proposal: Bridging the Gap

The WASI-OTel proposal represents a significant step forward for WebAssembly observability. Currently in Phase 0 of the WASI process, it provides:

Standardized interfaces for telemetry data exchange between host and guest
Processor callbacks (onStart, onEnd) that notify the host of guest span lifecycle events
Context propagation methods that enable proper trace parenting

The proposal is wrapped in language-specific SDKs (starting with Rust) that make it transparent for developers to use standard OpenTelemetry APIs while benefiting from WebAssembly-specific optimizations.

Looking Ahead

This work represents the evolution from earlier efforts like WASI-Observe to a more focused, OpenTelemetry-native approach. The community’s convergence around OpenTelemetry as the observability standard drove this decision, ensuring WebAssembly applications can integrate seamlessly with existing observability infrastructure.

Next steps include:

Advancing WASI-OTel through the WASI standardization process
Expanding language support beyond Rust
Adding metrics and logs support (currently focused on tracing)
Gaining broader runtime support beyond Spin

Why This Matters

As WebAssembly moves beyond experimental use cases into production-critical applications, observability becomes a prerequisite, not a nice-to-have. The combination of automatic instrumentation and developer-controlled custom tracing provides a compelling observability story that could accelerate WebAssembly adoption in enterprise environments. The work showcased here demonstrates that WebAssembly doesn’t have to be a black box.

With the right tooling and standards, it can provide even richer observability than traditional deployment models, thanks to the runtime’s deep understanding of component interactions and resource usage.

Why We Chose Rust For Spin

Jasmine Mae — Fri, 27 Jun 2025 15:41:53 +0000

By: Thorsten Hans

Beyond the Obvious: Our Journey into Rust

When Fermyon set out to implement Spin, the open-source framework for building serverless WebAssembly applications, the decision to use Rust wasn’t just logical - it felt inevitable. Sure, we could cite the obvious characteristics of Rust, like its memory safety guarantees without garbage collection, its blazing-fast performance, or its growing ecosystem. But for us at Fermyon, these reasons were only the beginning of the story. We appreciated the depth of Rust’s philosophy and tooling, and their alignment with our goals for Spin. Here’s why we chose Rust, and how it has helped us shape Spin into the powerful tool we envisioned.

It All Began With wasmtime

Spin assists you in building and running WebAssembly (Wasm) workloads. We use wasmtime as the WebAssembly runtime in Spin. wasmtime itself is written in Rust, and this gave us a significant head start. By choosing Rust for Spin, we gained immediate interoperability with wasmtime and access to its rich ecosystem of libraries and tools. This synergy allowed us to focus on crafting Spin’s remarkable developer experience and features while leveraging the stability and performance of wasmtime. In other words, Rust didn’t just complement our goals—it supercharged them.

The Developer Experience: A Core Objective

At Fermyon, we set ourselves an ambitious goal: to provide the best possible experience for developers working with Spin. This objective guided every decision we made, from the architecture to the implementation. Specifically, we envisioned Spin as a framework that developers could extend and personalize with ease. To achieve this, we introduced:

Spin Plugins

Rust’s modularity and ergonomic design, combined with the powerful clap crate, allowed us to build Spin’s highly extensible Command Line Interface (CLI).

clap provided the foundation for designing and implementing the Spin CLI and its plugin architecture, enabling a seamless and intuitive developer experience. With Spin Plugins, developers can extend Spin’s capabilities by leveraging community-contributed plugins or even creating their own. Notably, plugins themselves can be implemented using a wide range of programming languages, with Rust and Go being the most popular choices – as of today. Looking at the source code, we can see how sub-commands provided through plugins are added to the Spin CLI using APIs provided by clap:

#[derive(Parser)]
#[clap(name = "spin", version = version())]
enum SpinApp {
    // snip
    #[clap(alias = "n")]
    New(NewCommand),
    #[clap(alias = "b")]
    Build(BuildCommand),
    #[clap(alias = "u")]
    Up(UpCommand),
    #[clap(external_subcommand)]
    External(Vec<String>),
}

async fn _main() -> anyhow::Result<()> {
 // snip
 let mut cmd = SpinApp::command();
 for plugin in &plugin_help_entries {
   let subcmd = clap::Command::new(plugin.display_text())
     .about(plugin.about.as_str())
     .allow_hyphen_values(true)
     .disable_help_flag(true)
     .arg(clap::Arg::new("command")
       .allow_hyphen_values(true)
       .multiple_values(true));
   cmd = cmd.subcommand(subcmd);
  }
  if !plugin_help_entries.is_empty() {
    cmd = cmd.after_help("* implemented via plugin");
  }
  // snip
}

Custom Spin Plugins empowers developers to tailor Spin to their unique workflows and project requirements, fostering innovation and adaptability.

Spin Templates

Rust’s expressive type system and tooling enabled us to build Spin Templates, which are pre-defined scaffolds for creating Spin applications. These templates allow users to bootstrap new applications quickly and effectively. Template customization is powered by the Liquid template language and its Rust implementation provided by the liquid crate, offering flexibility and ease of use.

Additionally, we leverage the dialoguer crate to render a robust and user-friendly terminal user interface (TUI), simplifying the process of collecting template parameters and enhancing the overall developer experience.

The following snippet shows how spin new asks users for template parameters - using either Input or Select provided by dialoguer - when creating a new Spin application:

pub(crate) fn prompt_parameter(parameter: &TemplateParameter) -> Option<String> {
    let prompt = parameter.prompt();
    let default_value = parameter.default_value();

    loop {
        let input = match parameter.data_type() {
            TemplateParameterDataType::String(constraints) => match &constraints.allowed_values {
                Some(allowed_values) => ask_choice(prompt, default_value, allowed_values),
                None => ask_free_text(prompt, default_value),
            },
        };

        match input {
            Ok(text) => match parameter.validate_value(text) {
                Ok(text) => return Some(text),
                Err(e) => {
                    println!("Invalid value: {}", e);
                }
            },
            Err(e) => {
                println!("Invalid value: {}", e);
            }
        }
    }
}

fn ask_free_text(prompt: &str, default_value: &Option<String>) -> anyhow::Result<String> {
    let mut input = Input::<String>::new();
    input = input.with_prompt(prompt);
    if let Some(s) = default_value {
        input = input.default(s.to_owned());
    }
    let result = input.interact_text()?;
    Ok(result)
}

fn ask_choice(
    prompt: &str,
    default_value: &Option<String>,
    allowed_values: &[String],
) -> anyhow::Result<String> {
    let mut select = Select::new().with_prompt(prompt).items(allowed_values);
    if let Some(s) = default_value {
        if let Some(default_index) = allowed_values.iter().position(|item| item == s) {
            select = select.default(default_index);
        }
    }
    let selected_index = select.interact()?;
    Ok(allowed_values[selected_index].clone())
}

Furthermore, users could roll their own templates to enhance their productivity or to ensure alignment with specific regulatory compliance requirements, tailoring the development process to their unique needs.

Spin Factors

Spin Factors are a core design principle and pattern within the Spin codebase. They allow users and organizations to add or customize the behavior of the Spin Runtime (Host). This flexibility is pivotal in adapting Spin to specific needs and use cases, making it not only a tool but a platform that evolves with its users. By leveraging Spin Factors, developers gain the ability to shape the runtime itself, empowering them to innovate at a higher level.

For the sake of this article, let’s take a look at one of the unit tests that the team wrote for Spin Factors. The test implementation should give you a sense of Spin’s flexibility when it comes to creating a tailored runtime for running Spin Applications in restricted environments and only providing a subset of the default Spin Factors (key-value store in this instance).

#[derive(RuntimeFactors)]
struct TestFactors {
    key_value: KeyValueFactor,
}

impl From<RuntimeConfig> for TestFactorsRuntimeConfig {
    fn from(value: RuntimeConfig) -> Self {
        Self {
            key_value: Some(value),
        }
    }
}

#[tokio::test]
async fn works_when_allowed_store_is_defined() -> anyhow::Result<()> {
    let mut runtime_config = RuntimeConfig::default();
    runtime_config.add_store_manager("default".into(), mock_store_manager());
    let factors = TestFactors {
        key_value: KeyValueFactor::new(),
    };
    let env = TestEnvironment::new(factors).extend_manifest(toml! {
        [component.test-component]
        source = "does-not-exist.wasm"
        key_value_stores = ["default"]
    });
    let mut state = env
        .runtime_config(runtime_config)?
        .build_instance_state()
        .await?;

    assert_eq!(
        state.key_value.allowed_stores(),
        &["default".into()].into_iter().collect::<HashSet<_>>()
    );

    assert!(state.key_value.open("default".to_owned()).await?.is_ok());
    Ok(())
}

By incorporating these features and patterns, we’ve been able to bake extensibility directly into Spin, empowering users to shape the framework rather than be constrained by it.

Managing Code at Scale: How We Use Rust in the Spin Codebase

Spin is a large-scale project, and maintaining its complexity without losing simplicity requires discipline. Thankfully, Rust’s ecosystem is not just about writing code—it’s about writing manageable, maintainable, and scalable code. Below are three examples, outlining why Rust is invaluable for building and managing codebases at scale:

1. Cargo Workspaces

Cargo Workspaces are a game-changer for managing large projects. Spin is composed of multiple interdependent crates, and using workspaces allows us to organize these crates into logical units without sacrificing efficiency. Workspaces lay the foundation for increasing the end-to-end build performance, managing shared dependencies, centralized configuration management, simplifying development and reducing overhead. For example, the bespoke Spin plugin architecture, Spin Templates, and Spin Factors are managed as separate crates within a shared workspace, ensuring clean separation of concerns while maintaining cohesion.

2. Rust’s Strong Type System

Rust’s strong type system, coupled with its support for traits and generics, provides a powerful foundation for building scalable and maintainable codebases like Spin. Traits enable the definition of shared behaviors across diverse components, ensuring consistency and reducing duplication, while generics allow developers to write highly reusable abstractions that are both type-safe and performant. These features significantly enhance the robustness and adaptability of the Spin codebase, simplifying the management of its complexity as it grows. By leveraging Rust’s expressive type system, Spin achieves a higher level of reliability and clarity, making it easier to scale and maintain without compromising on speed or safety.

3. Powerful, Robust & Efficient Toolchain

cargo, rustfmt, clippy, rust-analyzer, and Rust’s robust unit testing capabilities together form a powerful ecosystem for managing large-scale projects like Spin.

cargo streamlines dependency management and builds, while rustfmt ensures consistent code formatting across the project.

clippy offers insightful linting capabilities, guiding developers toward best practices and preventing common programming pitfalls.

Meanwhile, rust-analyzer enhances development workflows through intelligent code navigation and suggestions, significantly accelerating productivity.

Combined with Rust’s native support for unit testing, these tools collectively empower developers to maintain clarity, reliability, and scalability in even the most complex codebases.

Why Rust Matters

Rust isn’t just a programming language; it’s a mindset. Its emphasis on safety, performance, and maintainability resonates deeply with our goals for Spin. By choosing Rust, we’ve been able to deliver a toolchain that is fast, reliable, and extensible—all without compromising on developer experience.

Rust allows us release new features at an incredible pace. As Spin continues to grow, we remain confident that Rust will scale with us, supporting our mission to redefine serverless development.

Conclusion

For those exploring Rust or questioning why others choose it, our experience with Spin offers a compelling case. Beyond its technical merits, Rust provides a foundation for creativity and scalability that few other languages can match. At Fermyon, we didn’t just choose Rust for what it is —we chose it for what it empowers us to build.

If you’re a developer intrigued by Rust, consider diving into the Spin codebase. You might discover that Rust isn’t just a tool for building software — it’s a framework for building possibilities.

AI at The Edge With Fermyon Wasm Functions

Jasmine Mae — Fri, 13 Jun 2025 16:20:32 +0000

By: MacKenzie Adam

Let’s start off this post with a short exercise in imagination.

It’s your first day at KubeCon. The smell of drip coffee and baked goods greets you, along with hundreds of sponsor booths lining the hallway, staffed with people eager to teach you how their technology can help you build more secure, efficient, and cost-effective software.

It can be an intimidating task, deciding how to split your time between perusing the conference floor, attending the talks most relevant to your interests, and making all those coffee chats you lined up before the event.

To take one task off your plate, we built KubeAround, an AI-powered scheduling assistant for conferences. Instead of manually sifting through the talk schedule (there were 229 sessions at KubeCon + CloudNativeCon Europe 2025!), you can simply ask KubeAround (via voice or text) to find the best sessions for your interests and availability. And it responds in milliseconds.

Try it live: KubeCon Japan Demo

How It Works

Under the hood, KubeAround is composed of several key parts:

Frontend, Edge-API & Key-Value Store deployed globally using Fermyon Wasm Functions
A centralized API implementing the Retrieval-Augmented Generation (RAG) pattern along with a central cache hosted on Akamai App Platform via open-source SpinKube
Multiple LLMs hosted on GPU-backed Linode instances
A vector database powered by Turso
Embedding Models powered by Fermyon Cloud to compute vectors Let’s dive into how these services work together to deliver a fast, secure, and delightful experience for both users and developers.

Globally Distributed Frontend, Edge-API and Key-Value Store

The frontend and Edge API are bundled into a single Spin application and deployed globally via the Fermyon Wasm Functions spin aka plugin. This gives us low-latency compute and fast content delivery at the edge. Leveraging the NoOps Key-Value Store provided by Fermyon Wasm Functions, we can generate recommendations for known questions in no-time.

Frontend Component

We chose Vue.js for its lightweight footprint and reactive data binding, which helps keep the UI fast and responsive. KubeAround’s frontend has a few responsibilites:

Capture user input (either voice or text)
Send user input to Edge-API
Display recommendations streamed from the Edge-API
Render a simple toggle to A/B test different Large Language Models (LLMs)

Static assets are served via Spin’s static file server template for lightning-fast load times. Here’s a snippet from the application manifest:

[[trigger.http]]
route = "/..."
component = "frontend"

[component.frontend]
source = { url = "https://github.com/fermyon/spin-fileserver/releases/download/v0.3.0/spin_static_fs.wasm", digest = "sha256:ef88708817e107bf49985c7cefe4dd1f199bf26f6727819183d5c996baa3d148" }
files = [{ source = "static", destination = "/" }]

# Build the Vue Frontend when `spin build` is executed
[component.frontend.build]
command = "npm install && npm run build && touch ../static/.gitkeep"
workdir = "frontend"

Spin’s capability-based security model ensures this component can only access the “files” directory, giving us a secure-by-default frontend.

If you’re interesting hosting a static site with Spin, we have plenty of starter templates available on Spin Hub including Jekyll, Zola, Angular, Tera, NextJS, 11ty, Docuusaus, Quik, Hugo, Dioxus.

The Edge-API component

The Edge-API hanldes communication between the frontend and backend services running on Akamai’s App Platform. This component is implemented in Typescript for ease of development, but could have just as easily have been written a performance sensitive language such as Rust thanks to the polyglot capabilities of WebAssembly. The main responsibilities of our Edge-API are to:

Translate voice input to text by sending it to Open-Whisper running on Linode GPU for transcription
Take user queries and model selection, check to see if we have a response in the Fermyon Wasm Functions Key Value Store; otherwise forward to our Central API for processing
Use Response teeing to cache new answers in the Edge Key-Value store and stream them to the frontend in parallel Within the application manifest, you can see our Edge-API has been granted the necessary capabilities required to complete these responsibilites:

[[trigger.http]]
route = "/api/..."
component = "api"

[component.api]
source = "api/dist/api.wasm"
# We use Key Value Store to cache recurring questions
key_value_stores = ["default"]
# Allow outbound connectivity to the central api running on Akamai App Platform
allowed_outbound_hosts = ["{{ central_api_endpoint }}"]

[component.api.build]
command = "npm install && npm run build"
workdir = "api"

Unlike the frontend component, our Edge-API component must have access to a Fermyon Wasm Functions Key Value store to pull in cached user queries and answers to deliver latency-sentitive data to our users. In the event we have a cache miss, it has permission to make outbound calls to the central-API for updated response.

Test Locally and Deploy Globally

KubeAround has been designed as a modular system, meaning we can independently test our frontend and edge-API components. To do so, we’ll run the spin build command:

$ spin build
Building component frontend with `npm install && npm run build && touch ../static/.gitkeep`
Working directory: "./frontend"
< ... > 
loaded configuration for: [ '@fermyon/spin-sdk' ]
asset bundle.js 32.7 KiB [emitted] [javascript module] (name: main)
orphan modules 44.3 KiB [orphan] 29 modules
runtime modules 396 bytes 2 modules
./src/index.ts + 11 modules 31.6 KiB [not cacheable] [built] [code generated]
webpack 5.98.0 compiled successfully in 633 ms
Using user-provided wit in: /PATH/knitwit
Component successfully written.
Finished building all Spin components

And then serve it locally with spin up:

$ spin up
Logging component stdio to ".spin/logs/"
Storing default key-value data to ".spin/sqlite_key_value.db".
Preparing Wasm modules is taking a few seconds...

Serving http://127.0.0.1:3000
Available Routes:
  api: http://127.0.0.1:3000/api (wildcard)
  frontend: http://127.0.0.1:3000 (wildcard)

A quick visit to localhost:3000 shows a local copy of our frontend and edge-API running on my machine:

Once we’re ready to move to production, we’ll deploy using the spin aka plugin. When we run the spin aka deploy command, Fermyon Wasm Functions will package our application, store it in a managed OCI registry, and distribute it across all available regions on our behalf.

Want to integrate with an existing Akamai property? Check out our Property Manager guide.

Centralized-API

Now we’re going to get into how the ~~sausage~~ session recommendations are made. The centralized-API turns queries into personalized schedule recommendations, leveraging a multi-step process as a Retrevial Augment Generation (RAG) service

A RAG service combines information retrieval with generative models by fetching relevant documents from a data source and using them to ground and enhance the output of an LLM

Embed sanitized user query using minilm on Fermyon Cloud GPUs
Cache sanitized user query embeddings in Valkey for faster future lookups
Query vector DB (Turso) for the most relevant conference sessions
Construct a prompt using retrieved results, model-specific instructions, and user preferences
Send to LLM (Llama 3.2 or DeepSeek on Linode GPUs) for a response
Stream response back to the Edge API

Our RAG service is implemented as a Spin application, running on Akamai’s App Platform thanks to SpinKube (an OSS project that allows you to run your Spin applications alongside traditional containerized applications on your Kubernetes cluster).

Here we can see the portability benefits in action for Spin. We’re continue to use the same format of application manifest, despite this Spin application running on Kubernetes rather than Fermyon Wasm Function’s managed platform.

A key design principle in this demo is multi-layered caching to improve responsiveness. For instance, the Central API layer includes a Valkey-backed key-value store to prevent repeated queries from being vectorized repeated queries quickly, even across different regions.

With the service’s responsibilties in mind, we can see this application has by far the largest reach as it must connect to our LLMs responsibily for generating user-facing recommendations, LLMs for generated embeddings, vector databases, key-value stores for caches. There are also serveral variables used to adjust the models output, such as similarity search limits and temperature.

[[trigger.http]]
route = "/..."
component = "api"

[component.api]
source = "dist/api.wasm"
exclude_files = ["**/node_modules"]
allowed_outbound_hosts = [
    "{{ llama_endpoint }}",
    "{{ alternative_model_endpoint }}",
]
# Use Fermyon Cloud to compute embeddings
ai_models = ["all-minilm-l6-v2"]

# Documents (sessions) are stored in a sqlite running on TursoDB
# See runtime configuration file
sqlite_databases = ["default"]

# Embeddings for questions are cached in key value store
# See runtime configuration file
key_value_stores = ["default"]

[component.api.variables]
llama_endpoint = "{{ llama_endpoint }}"
llama_identifier = "{{ llama_identifier }}"
alternative_model_endpoint = "{{ alternative_model_endpoint }}"
alternative_model_identifier = "{{ alternative_model_identifier }}"
similarity_search_limit = "{{ similarity_search_limit }}"
temperature = "{{ temperature }}"

[component.api.build]
command = ["npm install", "npm run build"]
watch = ["src/**/*.ts"]

Putting It All Together

We’ve covered a lot of ground together today—maybe not quite as many steps as you’d take during a week at the KubeCon conference, but close! KubeAround has shown us how distributed edge functions and caches make AI inferencing at the edge not just practical, but surprisingly powerful. For computationally intensive tasks that need to be colocated with a data source (what we affectionately call “heavy-weight functions”), we’ve learned how to host these workloads on Kubernetes clusters (such as the managed ones on Akamai App Platform) using SpinKube. With Akamai Cloud GPUs, deploying your preferred LLM is straightforward—in this demo alone, we ran three different LLMs handling everything from voice-to-text transcription to natural language processing.

If you’re planning on attending KubeCon Japan, swing by the Akamai Booth to see KubeAround in action. Otherwise, we’re around in Discord for all of your Fermyon Wasm Functions questions!

Rawkode's Hands-on Intro to Fermyon Wasm Functions

Jasmine Mae — Mon, 09 Jun 2025 01:08:42 +0000

Recently, Rawkode Academy recorded a deep dive with Fermyon Wasm Functions - where host David Flanagan and Thorsten Hans (of Fermyon) provide a hands-on session exploring the new serverless offering.

Fermyon Wasm Functions is a fully managed hosted service built on top of Akamai’s globally connected network. It takes the proven architecture of running Spin apps in a dense and available fashion and distributes them across multiple regions worldwide. This means your applications are always available, and requests are automatically routed to the closest data center based on the user’s location.

During the Rawkode Academy session, David and Thorsten discuss:

Benefits
Wasm Functions Setup
Demoing app scenarios
Deployment
Advanced Features
Use Cases and Examples

Benefits of Fermyon Wasm Functions

Lightning-Fast Cold Starts

While traditional containers measure startup time in hundreds of milliseconds, WebAssembly applications measure startup in nanoseconds. Combined with Akamai’s global network, this delivers consistently low latency regardless of user location.

Global Distribution Made Simple

Instead of manually selecting regions and managing deployments, Fermyon Wasm Functions automatically distributes your application globally. Developers can focus on building great applications rather than infrastructure management.

Familiar Developer Experience

The service extends the existing Spin CLI with an aka plugin, maintaining the familiar workflow developers already know while adding global deployment capabilities.

Getting Started

Prerequisites:

To get started with Fermyon Wasm Functions, you’ll need:

Spin CLI (version 3.2.0 or later)
Spin aka plugin to extend your Spin CLI

spin plugin install aka

Authentication

Fermyon Wasm Functions uses GitHub for authentication:

spin aka login

This initiates a device code flow where you’ll authenticate with your GitHub account and grant the CLI permissions to interact with Fermyon Wasm Functions on your behalf.

Building Your First Application

Creating a New Project

Fermyon has updated their templates to provide better developer experience. For TypeScript projects, you can now choose between different HTTP routers:

spin new http-ts hello-fermyon-wasm-functions

The new templates support popular frameworks like Hono, which provides an excellent API for building HTTP applications with clean middleware support.

App Demos

1. Simple Hello World
A basic application that responds with personalized greetings:

app.get('/', (c) => c.text('Hello Spin'))
app.get('/hello/:name', (c) => c.text(`Hello ${c.req.param('name')}`))

2. A/B Testing with Key-Value Store
A more advanced example implementing A/B testing using Fermyon’s globally distributed key-value store:

// Track request count
const counter = await store.getJson(HITS_KEY) || { count: 0 }
counter.count++
await store.setJson(HITS_KEY, counter)

// Return different content based on even/odd requests
if (counter.count % 2 === 0) {
    return c.html('<h1>Even</h1>')
} else {
    return c.html('<h1>Odd</h1>')
}

Deployment

Deploying to Fermyon Wasm Functions is straightforward:

spin aka deploy

This command:

Creates an OCI artifact from your Spin application
Pushes it to Fermyon’s registry
Deploys it across all regions
Provides a generated subdomain with HTTPS certificate

Advanced Features

Monitoring and Observability

The aka plugin provides several commands for monitoring your applications:

spin aka apps list - View all deployed applications
spin aka apps info [app-name] - Get detailed application information
spin aka logs [app-name] - View application logs

Cron Jobs (Experimental)

Fermyon Wasm Functions supports scheduled jobs:

spin aka cron create --route / --schedule "* * * * *" my-cron-job

CDN Integration

Applications automatically benefit from Akamai’s CDN. You can add cache control headers to enable caching:

response.headers.set('Cache-Control', 'max-age=10')

Configuration Management

For sensitive configuration like API keys, use Spin’s variable system:

spin aka deploy --variable secret_key=$SECRET_VALUE

Variables are encrypted and only exposed to your specific deployment.

Portability: A Key Advantage

One of WebAssembly’s greatest strengths is portability. The same application you deploy to Fermyon Wasm Functions can run:

Locally with spin up
On Kubernetes using SpinKube
On any other Spin-compatible platform

Use Cases and Examples

Fermyon provides a comprehensive repository of examples showcasing various use cases:

A/B Testing - Dynamic content serving based on user segments
Traffic Filtering - Request filtering and routing
Geo-blocking - Restricting access based on user location
Response Header Modification - Dynamic header manipulation
Gated Access - Time-based access control

These examples demonstrate how edge computing with WebAssembly enables new architectural patterns that weren’t practical with traditional serverless platforms.

Conclusion

The familiar developer experience, combined with powerful features like global key-value storage, cron jobs, and seamless CDN integration, makes it an compelling choice for building modern, high-performance web applications.

Whether you’re building APIs, implementing edge logic, or creating globally distributed applications, Fermyon Wasm Functions provides the tools and infrastructure to deploy your ideas worldwide with minimal complexity and maximum performance.

Ready to get started? Request access to Fermyon Wasm Functions and join the future of serverless computing.

Docs: developer.fermyon.com/wasm-functions
Examples Repository: github.com/fermyon/fwf-examples community examples and tutorials
Spin: spinframework.dev for the open-source Spin project
Hands-On Video: Watch the full demonstration

Forem: Jasmine Mae

A Bridge over Troubled Water: Sending Azure Alerts to Slack with Spin

Using Spin as a Service Bridge

Azure Slack Service Bridge Implementation

Using the Azure Slack Bridge Application to Monitor Cosmos DB

Step 1: Create an Incoming Slack Webhook

Step 2: Build and Deploy the Azure Slack Bridge Application

Step 3: Set Up the Azure Alert Pipeline

Seeing Alerts in Slack

A Bridge over Troubled Water

Introducing wasi-grpc for Spin

Tutorial

Step 1: Create a new Spin app

Step 2: Setup

Let’s implement!

Let’s take it for a Spin!

Conclusion

OpenAPI Documentation for Spin Apps with Rust

What is the OpenAPI Specification (OAS)

A Practical Guide To OpenAPI Documentation

Prerequisites and Setup

Exploring the ToDo-API

Meet the utoipa Crate

General API Documentation

API Request and Response Model Documentation

API Endpoint Documentation

Exposing The OpenAPI Description

Adding OpenAPI Documentation UI

Customizing OpenAPI Description

Conclusion

Running Cloudflare Workers Inside Spin Apps

Getting Started

Creating a Spin App

Create a Worker

Calling the Worker from Spin

Deploying a Worker to a Spin runtime

Next Steps

Supercharging Spin Applications with Wizer

Why Wizer?

Example Use-Case: Lightning-Fast GeoIP Lookup

Integrating Data Into a Spin Application

Under the Hood: Browsing the source code

Building and Testing the Spin Application

Deploying to Fermyon Wasm Functions

Conclusion

Building a GraphQL API with Fermyon Wasm Functions

What We’re Building

Prerequisites

Setting Up Your Development Environment

Understanding the GraphQL Schema and Query

Implementing the GraphQL Client

Type-Safe GraphQL Code Generation

Secure Token Management with Spin Variables

Building and Sending the GraphQL Request

Processing the GraphQL Response

URL Parsing and Error Handling

Configuration with spin.toml

Security Features

Building and Testing Locally

Deploying to Fermyon Wasm Functions

Conclusion

Running Serverless Wasm Functions on the Edge with k3s and SpinKube

Traditional Serverless

Why WebAssembly is Perfect for Serverless

Introducing Spin and SpinKube

How SpinKube Integrates with Kubernetes

Getting Started with Rancher Desktop

Building Your First Spin Application

1. Create a New Project

2. Build the Application

3. Deploy to Kubernetes

4. Test Your Function

The Power of Integration

Performance Benefits

Next Steps

Serverless A2A with Spin

What is an Agent?

What is A2A?

Discovery with Agent Cards

Inter-agent Interaction with JSON-RPC

Meet the `utoipa` Crate

Configuration with `spin.toml`