Understand and build the HTTP application

Get the application source

With wash and Rust set up, build the HTTP application.

Download and extract the sample application archive, then navigate to the project directory:

    

        
        
cd ~/wasmcloud-learning-path
curl -fLO https://learn.arm.com/learning-paths/servers-and-cloud-computing/wasmcloud/_examples/hello-http.tar.gz
tar -xzf hello-http.tar.gz
cd hello-http

    

The archive includes source and isn’t a precompiled application. You’ll build the component on your Graviton-based server.

Understand the handler

Open src/lib.rs:

    

        
        
cat src/lib.rs

    

The handler implementation is:

    

        
        
impl Guest for Component {
    fn handle(_request: IncomingRequest, response_out: ResponseOutparam) {
        let response = OutgoingResponse::new(Fields::new());
        response.set_status_code(200).unwrap();
        let body = response.body().unwrap();
        ResponseOutparam::set(response_out, Ok(response));

        let stream = body.write().unwrap();
        stream.blocking_write_and_flush(b"hello from wasmCloud").unwrap();
        drop(stream);
        OutgoingBody::finish(body, None).unwrap();
    }
}

    

The function receives a request and creates an HTTP response with status 200. It then writes a fixed greeting to its body and ignores the request contents. There’s no database, external network call, or substantial computation in the handler.

The surrounding wit_bindgen::generate! and export!(Component) statements generate the bindings and export the implementation. The WebAssembly Interface Types (WIT) language describes the interfaces between components and hosts.

Read the interface declaration:

    

        
        
cat wit/world.wit

    

The expected output is:

    

        
        package wasmcloud:http-handler-p2;

world http-handler-p2 {
    export wasi:http/incoming-handler@0.2.2;
}

        
    

This declares an incoming HTTP handler export. The component implements the handler but doesn’t open the TCP listening port of the server.

Build the WebAssembly component

Inspect the wash configuration:

    

        
        
cat .wash/config.yaml

    

The expected output is:

    

        
        
build:
  command: cargo build --target wasm32-wasip2 --release
  component_path: target/wasm32-wasip2/release/http_handler_p2.wasm
dev:
  address: "127.0.0.1:8000"

    

The build command selects the WebAssembly target and release profile. The component path tells wash where to find the result. The development listener uses loopback, so you don’t need to open an HTTP port in the EC2 security group.

Build the application:

    

        
        
source "$HOME/.cargo/env"
rustup target add wasm32-wasip2
wash build
ls -lh target/wasm32-wasip2/release/http_handler_p2.wasm

    

The output is similar to:

    

        
        -rw-rw-r-- 2 ubuntu ubuntu 95K Nov  4 15:26 target/wasm32-wasip2/release/http_handler_p2.wasm

        
    

wash resolves the local WIT dependencies and runs the configured Cargo build. The result is http_handler_p2.wasm.

The first build also creates Cargo.lock. Retain it if you want to rebuild the application later.

Your wash executable is an aarch64 program. The application that you built is a WebAssembly component that you’ll run on the host. These are separate artifacts.

What you’ve accomplished and what’s next

You’ve read the handler, identified its HTTP interface, and built its .wasm artifact.

Next, you’ll load that artifact into the development host and send a request.