How to make web-to-worker calls with RPC

When your front end calls your back end, the usual ceremony is a REST or GraphQL layer: design endpoints, write fetch calls, parse responses, keep the client's idea of the shapes in sync with the server's by hand. Base's RPC lets the browser call your worker's procedures as typed function calls instead, sharing the procedure types across the network boundary. This post is the public half of RPC, the one that faces your users' browsers.

Public visibility opens the door, on purpose

For the browser to call a procedure, the RPC service must be public: callable from a public route, reachable by a client outside your worker. This is the deliberate counterpart to the internal services you keep between workers. You expose exactly the procedures you mean to expose by marking them public, and nothing else is reachable from the web.

That explicitness matters more on the public side than anywhere else, because this surface faces the open internet. A procedure is public because you said so, not because a default left it open. The visibility setting is your audience decision, stated in the code.

The client in the browser

Base ships a dedicated client package for calling workers from a browser or another worker. The browser uses it to call your public procedures with the same typed-function feel as server-side RPC: name the procedure, pass typed arguments, receive a typed result. Because the client is typed against the service, your front-end code knows the procedures, their arguments, and their return types, and a change on the server surfaces as a type error in the client.

That shared-type boundary is the real win for web-to-worker calls. The front end and the back end are not two codebases guessing at each other's JSON. They share the procedure's type, so the contract between client and server is checked the same way a function signature is checked within a single codebase.

Errors cross the boundary too

The client is also an error client. When a procedure fails on the worker, the failure comes back to the browser in a structured form rather than as an opaque network error, so the front end can react to what actually went wrong. Errors are part of the typed contract, not an afterthought left to status codes and string parsing.

REST, GraphQL, or RPC from the web

RPC does not replace REST or GraphQL; it sits beside them as another way to expose your worker. Reach for public RPC when your front end and back end are both yours and you want the call to feel like a typed function rather than a described HTTP resource. Reach for REST or GraphQL when you want a described, conventional surface for third parties or tooling. Base lets a worker offer whichever fits, from the same settings object.

The mental model to keep

Web-to-worker RPC is your browser calling your worker like a typed function: mark the service public to face the web, use Base's client package in the front end to call procedures with shared types, and get structured errors back across the boundary. It trades the ceremony of a hand-maintained HTTP client for a contract the compiler checks on both sides.