HTTP Task manager
This web component tracks and updates information about asynchronous tasks, backed by a Postgres Database.
Clients can make HTTP requests to endpoints like the following:
Endpoint | Description |
---|---|
GET /tasks | List ongoing tasks |
POST /tasks/:id/status | Get status of a specific task |
POST /tasks | Submit a new task |
Tasks can also be submitted over the wasmCloud Lattice (i.e. via wRPC), rather than simply via HTTP.
Architecture
This application requires a few other pieces to function:
- wasmCloud HTTP server for receiving incoming HTTP requests
- wasmCloud SQLDB Postgres Provider for persistence of tasks
Prerequisites
cargo
>= 1.81wash
>=0.30.0docker
(or some other means to easily run Postgres instances)
Build
You can build the HTTP task manager component with the WAsmcloud SHell wash
:
wash build
Note that if you'd like to build with cargo
you need to specify the --target
option:
cargo build --target=wasm32-wasip1
Launch
Start dependencies
As the application depends on a Postgres instance for persistence, let's start an ephemeral one:
docker run \
--rm \
-p 5432:5432 \
-e POSTGRES_PASSWORD=postgres \
--name pg \
postgres:16-alpine
Start the application
Now, we're ready to start our component along with the required providers.
First we start a new wasmCloud host:
wash up
[!NOTE] This command won't return, so run open a new terminal to continue running commands
To enable our application we'll start to connect to Postgres requires setting up some configuration with wash
:
wash config put default-postgres \
POSTGRES_HOST=localhost \
POSTGRES_PORT=5432 \
POSTGRES_USERNAME=postgres \
POSTGRES_PASSWORD=postgres \
POSTGRES_DATABASE=postgres \
POSTGRES_TLS_REQUIRED=false
[!NOTE] In production, you'll want to use wasmCloud secrets to set up the required configuration.
Next, we deploy our application:
wash app deploy ./local.wadm.yaml
We can confirm that the application was deployed successfully:
wash app list
Once the application reports as Deployed in the application list, you can use curl
to send a request to the running HTTP server.
We'll hit the /ready
endpoint:
curl localhost:8000/ready
You should receive output like the following:
{"status":"success"}
Migrating the database
Since this application uses a database, we must migrate the database that uses it. For relative ease of use, the application has been written such that it can migrate it's own database (and migrations are written idempotently).
While normally a separate component (or manual DB administrator action) would trigger migrations, we can trigger a migration via HTTP:
curl -X \
POST -H "Content-Type: application/json; charset=utf8" \
localhost:8000/admin/v1/db/migrate
Regardless of how many times you run the migration, you should receive the output below:
{"status":"success"}
Adding a new task
To try out adding a new task we can use curl
:
curl \
-X POST \
-H "Content-Type: application/json; charset=utf8" \
localhost:8000/api/v1/tasks \
--data '{"group_id": "test", "task_data": {"one":1}}'
Getting a list of existing tasks
To retrieve all existing tasks:
curl localhost:8000/api/v1/tasks
[!NOTE] If you have
jq
installed, this would be a great time to use it!
Tests
You can run the full E2E test suite:
cargo test