Skip to main content

Crate edda_server

Crate edda_server 

Source
Expand description

What every edda service shares: logging, opening its database, finding the auth service’s key, serving (with the CORS setting and the limits), error responses, and the conventions of their OpenAPI descriptions.

Re-exports§

pub use limits::Limits;

Modules§

admin
The admin API: what whoever runs the services asks of them over HTTP, such as creating and deleting campaigns, so a hosting’s control plane can do it without a shell. Served on ADMIN_ADDR, an address only it can reach, and only with ADMIN_TOKEN too, which every request must bear; without both there’s none.
limits
Limits on how much one client or one campaign can ask of a service, so a service open to the internet can’t be flooded or filled up: requests per minute from each client address (fewer for signing in), how big a request may be, and how much each campaign may keep.
measure
What a service measures, for Prometheus: its requests by route and status and how long they take, what the limits refuse, and its database connections; services add their own (the combat service’s WebSockets, say). Served at /metrics on METRICS_ADDR, an address of its own that the proxy never serves; without it nothing is measured.
observe
What a service logs about each request: a span with its method, path, request id, and whose it is (the campaign, once its token is checked, and the account, as the proxy says), in plain text or JSON lines, and as traces to an OpenTelemetry collector if there is one. Never a body, and never the query string, which may hold what someone typed.
openapi
What every service’s OpenAPI description shares: the token routes need, and the error responses any route may give.

Functions§

auth_key
The key the auth service signs tokens with: AUTH_PUBLIC_KEY if set, otherwise fetched from the auth service at auth_service (waiting a while for it to start). Set the key explicitly unless the network between the services is trusted.
auth_service_url
AUTH_SERVICE_URL, or the auth service on this machine.
direct_database_url
Where to reach the database for what needs a session of its own: migrations, and the combat service’s LISTEN. DATABASE_DIRECT_URL when url goes through a pooler that hands out connections per transaction (PgBouncer’s transaction mode), otherwise url itself.
error_message
What an error response says: the error itself, unless it’s internal (a 500), which is logged and not shown.
error_response
An error response: {"error": "..."} with status (see error_message).
health
GET /health: answers ok while the service runs.
init_logging
Logs to stderr: crate_name’s own messages, this crate’s (serving, internal errors) and each request, at info, unless RUST_LOG says otherwise. LOG_FORMAT=json writes a JSON object a line, for a log collector, and OTEL_EXPORTER_OTLP_ENDPOINT sends traces to an OpenTelemetry collector; see observe.
open_database
A connection pool to the service’s Postgres database at url, after creating the database if there’s none yet and bringing it up to date with migrations. Those two go through direct_database_url, as they need a session of their own (sqlx serialises migrations with an advisory lock, so instances may start at once).
readiness
GET /ready, for whatever runs the service (Kubernetes, compose): 200 while it can reach its database, 503 while it can’t, so it gets no requests until it can again. /health only says it’s running.
ready
GET /ready: see readiness.
serve
Serves app on bind until asked to stop, within limits, answering web pages from the origins in CORS_ORIGINS; and admin on ADMIN_ADDR and metrics on METRICS_ADDR, if set.