Server

acor/server turns a keyword collection into a service: an HTTP/JSON API, a gRPC API, and the middleware that makes either observable.

The acor/server module is experimental. It lives in the separate github.com/skyoo2003/acor/server module, which publishes no version tags of its own and is not covered by the core module’s compatibility promise — its API can change in any release. The core library (pkg/acor) is unaffected.

go get github.com/skyoo2003/acor/server resolves a pseudo-version from main. Pin the core module explicitly in the same go.mod: Go ignores a dependency’s own replace directive, so without a pin you get whichever core version the server module’s require names.

ACOR ships no server binary

There is no acor-server to install, and no image to pull. acor/server is a library: it hands you an http.Handler, a *grpc.Server, and middleware, and you write the main that wires them to a collection and listens.

That is a deliberate consequence of the module being experimental — a published binary is a contract, and this module does not offer one yet. What it offers instead is that the wiring is about forty lines, and Running a Server is those forty lines, complete and copy-pasteable.

Sections

  • Running a Server - Wire a collection to HTTP or gRPC, with readiness checks and clean shutdown
  • HTTP API - The nine JSON endpoints, their request and response shapes, and every error they return
  • gRPC API - The acor.server.v1.Acor service, its eight RPCs, and the observability constructors

Metrics, structured logging, and tracing are configured the same way whichever protocol you serve, so they live together under Operations → Monitoring.

Operations | CLI