SERVER / QUEUE
Deliver durable work
Queue provides durable work queues and topic pub/sub with explicit delivery decisions. The same server contract serves local Dowe storage, RabbitMQ, Cloudflare Worker bindings, and Vercel Queues.
1 / TOPOLOGY
Bindings decide where a message goes
Topics use dot-separated words. A star matches one word and a hash matches zero or more words. Publishing copies a message to every matching queue.
dowe queue init jobs
dowe queue declare jobs email-workers
dowe queue declare jobs email-notifications
dowe queue bind jobs email-workers orders.*
dowe queue bind jobs email-notifications orders.*
dowe queue publish jobs orders.created '{"id":"order-42"}'Rule | What happens |
|---|---|
No dataThere are no records to display | |
A live service, second server, and local CLI cannot directly own the same namespace concurrently. Lock acquisition fails closed; use the authenticated service protocol for a namespace owned by a running service.
2 / DELIVERY
At-least-once, session-bound decisions
Each subscription keeps its own streaming session. An opaque receipt can be acknowledged or rejected only once and only on that session.
Decision | Effect |
|---|---|
No dataThere are no records to display | |
3 / PROVIDERS
One contract, four provider boundaries
The provider API and CLI share local and native publication semantics while deploy adapters connect edge handlers to the selected provider.
Provider | What it owns |
|---|---|
No dataThere are no records to display | |
Remote Dowe Queue and RabbitMQ connections require TLS. Cloudflare uses the generated Worker binding; Vercel uses its regional HTTPS API.
4 / DOWE QUEUE
Run the maintained service
The host reserves one authenticated WebSocket path, takes exclusive ownership of each opened namespace, and leaves Queue operations to the shared Rust crate.
main
server port:4150
queue serviceAccount writers use .dowe/queue/_auth/.lock for exclusive read-modify-write and atomic replacement. A second writer fails closed instead of losing an account record.
dowe queue create-account jobs jobs-api
dowe dev --target server
dowe queue inspect jobs5 / SERVER-ONLY APPLICATION API
Publish to an existing queue
Server actions can select Dowe, RabbitMQ, Cloudflare, or Vercel and publish JSON directly to a named queue. The connection, credentials, and payload stay on the server.
handler enqueueNotification
queue appQueue provider:"dowe" host:env.QUEUE_HOST port:env.QUEUE_PORT account:env.QUEUE_USER secret:env.QUEUE_PASSWORD vhost:env.QUEUE_VHOST
msg sent conn:appQueue.publish queue:"notifications" payload:{ userId:"123" event:"user_created" }
return json:{ ok:sent.ok messageId:sent.id }Declare QUEUE_HOST, QUEUE_PORT, QUEUE_USER, QUEUE_PASSWORD, and QUEUE_VHOST in the root .env.example with empty or placeholder values. During dowe dev every provider uses local Dowe; deploys resolve the selected .env.live, .env.stage, or .env.uat values. Never expose secrets to Views.
Boundary | Rule |
|---|---|
No dataThere are no records to display | |
6 / CLI
Inspect and administer local namespaces
The root command calls the same Rust implementation used by runtime and IPC. Direct local commands fail closed when a live service owns the namespace lock.
Area | Use |
|---|---|
No dataThere are no records to display | |
7 / CURRENT SUPPORT
Finite publication, streaming consumption
Dowe Source Format supports queue service, server-only Queue connections, and direct msg publish. Cloudflare and Vercel edge handlers support one static publication per handler; dynamic actions and source-level consume, subscribe, ACK, and NACK remain native Rust provider APIs. Secrets, receipts, and payloads remain server-only.