a6a744b45f
Root `make check` only ever ran the frontend, so the "main is always green" policy was satisfied vacuously: the Go backend could be entirely broken and the root gate stayed green. - The backend moves onto scripts-to-rule-them-all. Its test, lint, fmt, fmt-check, build, run and clean implementations now live in `backend/script/`, and `backend/Makefile` is thin shims. The backend is its own project (own module, README, LICENSE, linter config, Dockerfile stage), and `Dockerfile.backend` only copies `backend/` into its builder, so its scripts have to live under `backend/`. - The root `script/test`, `script/lint`, `script/fmt` and `script/fmt-check` now run the frontend step and then the matching `backend/script/*` step, so `script/check` — and therefore the pre-commit hook — gates both halves. The frontend-only steps moved into `script/frontend-*` so nothing is duplicated. - `script/frontend-check` is the frontend half of the gate, exposed as the `check-frontend` target, for the frontend Dockerfile: its build stage is a node image with no Go toolchain. The backend half is gated by `Dockerfile.backend`, and `script/cibuild` builds both images, so the two Dockerfiles together still gate the whole repo. The `check-backend` target is the mirror of it. - `script/cibuild` builds both images through one `build_image` helper, and the Gitea workflow's only build step is `script/cibuild`; the raw `docker build -f Dockerfile.backend .` is gone from the workflow. `script/docker` likewise builds and tags both images. - `backend/Makefile`'s `hooks` target is removed. It wrote the same `.git/hooks/pre-commit` as `script/install-precommit`, so the two clobbered each other and the developer silently ended up gating on only one half of the repo. `script/install-precommit` is now the only installer, and the hook it writes runs the repo-wide `script/check`. - `backend/Makefile`'s `docker` target is removed too: the backend image builds from the repo root with a root-level Dockerfile, so it belongs to the root `script/docker` and `script/cibuild` rather than to a backend script that would have to reach outside `backend/`. - `backend/script/lint` verifies that `.golangci.yml` still matches its pinned sha256 before running the linter. Offline hash comparison, no network. READMEs at the root and in `backend/` document every script, and `TODO.md` records the change.
netwatch-server is an MIT-licensed Go HTTP backend by @sneak that receives telemetry reports from the NetWatch SPA and persists them as zstd-compressed JSONL files on disk.
Getting Started
# Build and run locally
make run
# Run tests, lint, and format check
make check
# Docker (from the repo root; the image's build context is the repo root)
make docker
docker run -p 8080:8080 netwatch-server
Entrypoints
This project follows the same
Scripts to Rule Them All
pattern as the repo root: the implementations live in backend/script/ and the
targets in backend/Makefile are thin shims that call them. The repo root's
script/test, script/lint, script/fmt and script/fmt-check call these
too, so the root make check covers the backend.
script/build— compilenetwatch-serverwith the version and architecture stamped in via ldflags (statically linked on Linux)script/test— run the Go tests under a 30-second timeoutscript/lint— assert.golangci.ymlstill matches its pinned sha256, then run golangci-lintscript/fmt— format the Go sources (writes)script/fmt-check— check Go formatting (read-only)script/check— run test, lint, and fmt-checkscript/run— build and run the server locallyscript/clean— remove build artifacts
There is deliberately no hooks target here: the repo has exactly one
pre-commit hook installer, the root script/install-precommit, and the hook it
installs runs the root script/check, which gates both halves of the repo.
There is no docker target either: Dockerfile.backend lives at the repo root
and builds with the repo root as its context, so the backend image is built by
the root make docker and by script/cibuild.
Rationale
The NetWatch frontend collects latency measurements from the browser but has no
way to persist or aggregate them. This backend provides a minimal
POST /api/v1/reports endpoint that buffers incoming reports in memory and
flushes them to compressed files on disk for later analysis.
Design
The server is structured as an fx-wired Go application under cmd/netwatch-server/.
Internal packages in internal/ follow standard Go project layout:
config: Loads configuration from environment variables and config files via Viper.handlers: HTTP request handlers for the API (health check, report ingestion).reportbuf: In-memory buffer that accumulates JSONL report lines and flushes to zstd-compressed files when the buffer reaches 10 MiB or every 60 seconds.server: Chi-based HTTP server with middleware wiring and route registration.healthcheck,middleware,logger,globals: Supporting infrastructure.
Configuration
| Variable | Default | Description |
|---|---|---|
PORT |
8080 |
HTTP listen port |
DATA_DIR |
./data/reports |
Directory for compressed reports |
DEBUG |
false |
Enable debug logging |
Report storage
Reports are written as reports-<timestamp>.jsonl.zst files in DATA_DIR.
Each file contains one JSON object per line, compressed with zstd. Files are
created with O_EXCL to prevent overwrites.
TODO
- Add integration test that POSTs a report and verifies the compressed output
- Add report decompression/query endpoint
- Add metrics (Prometheus) for buffer size, flush count, report count
- Add retention policy to prune old report files
License
MIT. See LICENSE.