Skip to content
ramose.ai

Use Ramose from a Worker

Application Workers can call Ramose through its authenticated server protocol. The same schemas, operations, and policy apply.

Use the supported server protocol

Section titled “Use the supported server protocol”

Ramose exposes server queries and operation invocation through its MCP endpoint. Authenticate requests with a principal whose policy grants match the caller’s work. A Worker can make these requests using its ordinary HTTP facilities.

There is currently no public request-scoped TypeScript database client, ramose.open method, or generated entity handle for Workers. The ramose/client entry is a browser replica client and requires browser storage.

Deploy the runtime

Section titled “Deploy the runtime”

Use Server and Database from ramose to declare deployment resources. Use createServer and the Durable Object exports from ramose/worker in the runtime entrypoint. Follow the deployment guide for schema installation and authentication.

Bind a server to an application Worker

Section titled “Bind a server to an application Worker”

serverBinding returns the native Worker resource behind a deployed Server:

import { serverBinding } from "ramose"


const deployedServer = yield* server
const web = yield* Cloudflare.Worker("Web", {
  main: import.meta.resolve("./web.ts"),
  env: { DATA: serverBinding(deployedServer) },
})

In the native Worker entry, forward database requests with env.DATA.fetch(request). Keep authentication and origin checks at the appropriate service boundary.

Invoke product operations

Section titled “Invoke product operations”

Discover an operation’s catalog identity, supply its validated input and target when required, and retain its invocation id across retries. The server applies the same owned operation and policy definitions used by browser applications.

Background jobs need an explicit service principal whose grants match the job. Record the operation and resulting receipt so retries preserve the original invocation identity.

Long-running workflows

Section titled “Long-running workflows”

One operation transacts inside the configured database. For work that spans external services:

  1. Commit a workflow entity and current state.
  2. Perform one external step.
  3. Invoke another operation to record success or a recoverable failure.
  4. Resume by stable workflow identity after retries.

This makes partial progress visible and avoids claiming atomicity the platform cannot provide.

Map errors deliberately

Section titled “Map errors deliberately”

Translate unauthenticated and inaccessible results without leaking hidden resource existence. Treat domain operation rejection as an expected product outcome. Retry temporary availability failures with the same invocation id; do not retry invalid input, policy denial, or query budget failures unchanged.