Skip to main content

Overview

World Monitor uses sebuf, a TypeScript-native RPC framework built on Protocol Buffers. This proto-first approach provides:
  • Type safety — Compile-time checking across client and server
  • Auto-generated code — Clients, servers, and OpenAPI specs from .proto files
  • HTTP/JSON transport — Web-standard REST-like endpoints
  • Breaking change detectionbuf breaking catches API incompatibilities

Workflow

1. Define Service

Create a .proto file in proto/worldmonitor/<domain>/v1/:

2. Define Messages

Create request and response messages:

3. Generate Code

Run the code generator:
This creates:

4. Implement Handler

Create a server-side handler in server/worldmonitor/<domain>/v1/handler.ts:

5. Register Routes

Wire the handler into the router (vite.config.ts for dev, Vercel for prod):

6. Call from Client

Use the generated client in your frontend:

Generated Client API

The generated client provides a type-safe interface:
Features:
  • Automatic serialization — Messages are JSON-encoded
  • Custom fetch — Inject your own fetch (useful for testing)
  • Error handling — HTTP errors throw with status codes

Generated Server API

The generated server creates HTTP routes:
Each route includes:
  • HTTP method — GET, POST, PUT, DELETE
  • Path pattern/api/seismology/v1/list-earthquakes
  • Handler — Executes your service implementation

HTTP Mapping

Request Mapping

Example Mappings

Service Domains

World Monitor defines 20 service domains:

Buf CLI Commands

Generate Code

Runs buf generate with plugins configured in proto/buf.gen.yaml:

Lint Protos

Checks proto files against style rules:
  • Service names must end with Service
  • RPC names must use PascalCase
  • Field names must use snake_case

Detect Breaking Changes

Compares current proto definitions against main branch:
  • Field removals
  • Field type changes
  • Field number changes

Format Protos

Auto-formats proto files using buf format.

Update Dependencies

Updates proto dependencies defined in proto/buf.yaml.

OpenAPI Generation

Every service generates OpenAPI 3.0 specs in docs/api/:
These specs can be imported into:
  • Postman — API testing
  • Swagger UI — Interactive documentation
  • OpenAPI Generator — Client generation for other languages

Desktop Sidecar Bundling

The Tauri desktop app runs a local Node.js sidecar that serves all API handlers. The sidecar bundle is built separately:
This script (scripts/build-sidecar-sebuf.mjs):
  1. Bundles api/[domain]/v1/[rpc].ts with esbuild
  2. Outputs a single ESM file: api/[domain]/v1/[rpc].js
  3. The sidecar discovers and loads this file at runtime

Best Practices

Service Design

Keep services small and focused. Each service should handle one domain (e.g., seismology, aviation).
Never break wire compatibility. Changing field numbers or types breaks existing clients.

Versioning

All services use v1 for now. When breaking changes are needed, create a new v2 package alongside v1.

Error Handling

Handlers should throw errors with HTTP status codes:
The server automatically maps these to HTTP error responses.

Testing

Test handlers using the generated client:

Next Steps

Building

Build production and desktop apps

Testing

Run E2E and API tests