Decision needed: the backend is not connected to anything — does it ship in 1.0? #25

New Issue

clawbot · 2026-08-09T03:43:57+02:00

clawbot commented

2026-08-09 03:43:57 +02:00

The finding

The Go backend is live, builds, has CI, and is deployed as its own image — and nothing uses it. Verified on main at fbfe1df:

The SPA never calls it. Grepping src/main.js for reports, clientId, or /api/ returns zero matches. The frontend collects all the telemetry that POST /api/v1/reports is designed to receive and never sends any of it.
nginx never routes to it. nginx.conf has no proxy_pass — only try_files (line 20) and the /assets/ block (line 24). The Go service is not behind this nginx. The two components have no network path between them.
The report schema exists on both sides but is unexercised. backend/internal/handlers/report.go:10-28 defines reportSample, reportHost, report with a clientId/geo/hosts/timestamp shape that clearly anticipates the frontend's data model, but no code produces it.

So the ingest endpoint is a fully-built, internet-facing, unauthenticated write path (see #20) serving no traffic and no purpose in the current deployment.

Why this needs a decision from you

Several open issues change shape depending on the answer, and I do not want implementers guessing:

#20 (unauthenticated write endpoint, wildcard CORS, no rate limiting) is a 1.0 blocker only if the endpoint is exposed. If the backend is not shipping, the cheapest correct fix is to not expose it.
#19 (trusted-proxy client IP) only matters behind a proxy that actually forwards to it.
#23 (report ingest correctness) is polishing a code path with no callers.
#21 (real tests) — how much test investment reportbuf deserves depends on whether it is production code or a prototype.
#22 (shutdown loses buffered reports) is a data-loss bug only if there is data.

Options

(a) Wire it up — the backend is part of 1.0.
Frontend gains a reporting client that POSTs periodically; nginx.conf gains a location /api/ with proxy_pass to the backend; the two images get a compose file or equivalent so they are deployable together. This makes #19/#20/#22/#23 genuine 1.0 blockers and adds real work: a reporting client, a retention/quota policy for DATA_DIR (currently unbounded — reportbuf.go:161-198 has no retention, and backend/README.md:62 lists it as an open TODO), and an answer to what the stored data is actually for.

(b) Ship 1.0 frontend-only; the backend stays in-tree but unreleased.
Tag 1.0.0 on the SPA. The backend keeps building in CI so it does not rot, but is explicitly documented as unreleased and not deployed. #19/#20/#23 drop off the 1.0 milestone and become post-1.0. #22 (shutdown data loss) and #21 (tests) stay, at reduced priority, because they are correctness debt either way.

(c) Remove the backend from the repo.
Delete it, or move it to its own repository. Cleanest possible 1.0: the README's current "zero-dependency SPA, no backend required" framing becomes true again, and roughly a third of the open backlog evaporates. Reversible via git history.

Recommendation

(b). The backend is well-built and clearly intended, so deleting it (c) discards real work for a tagging convenience. But (a) is a substantial feature — a reporting client, a retention policy, and a deployment story — and none of it is written down as a requirement anywhere. Gating the first tag on inventing that scope is how 1.0 slips indefinitely.

(b) lets the SPA — which is finished and works — get its tag, while keeping the backend healthy in CI until you decide what it is for. It also immediately de-risks the security posture, because an unexposed endpoint cannot be abused.

If you pick (b), I would additionally suggest closing #20 as post-1.0 rather than leaving it open against the milestone, and adding an explicit line to the README stating the backend is unreleased so the next reader does not assume it is deployed.

What I need

Pick (a), (b), or (c). Assigning to you. I will re-scope the affected issues and the 1.0.0 milestone accordingly.

Meanwhile I am proceeding with the work that is correct under all three options: #14 (lint config is invalid), #15 (dotfiles), #16 (unified gate), #17 (Dockerfile pattern), #18 (frontend security headers), #24 (documentation accuracy). None of those depend on this answer.

## The finding The Go backend is live, builds, has CI, and is deployed as its own image — and **nothing uses it**. Verified on `main` at `fbfe1df`: 1. **The SPA never calls it.** Grepping `src/main.js` for `reports`, `clientId`, or `/api/` returns **zero matches**. The frontend collects all the telemetry that `POST /api/v1/reports` is designed to receive and never sends any of it. 2. **nginx never routes to it.** `nginx.conf` has no `proxy_pass` — only `try_files` (line 20) and the `/assets/` block (line 24). The Go service is not behind this nginx. The two components have no network path between them. 3. **The report schema exists on both sides but is unexercised.** `backend/internal/handlers/report.go:10-28` defines `reportSample`, `reportHost`, `report` with a `clientId`/`geo`/`hosts`/`timestamp` shape that clearly anticipates the frontend's data model, but no code produces it. So the ingest endpoint is a fully-built, internet-facing, unauthenticated write path (see #20) serving no traffic and no purpose in the current deployment. ## Why this needs a decision from you Several open issues change shape depending on the answer, and I do not want implementers guessing: - **#20** (unauthenticated write endpoint, wildcard CORS, no rate limiting) is a 1.0 blocker only if the endpoint is exposed. If the backend is not shipping, the cheapest correct fix is to not expose it. - **#19** (trusted-proxy client IP) only matters behind a proxy that actually forwards to it. - **#23** (report ingest correctness) is polishing a code path with no callers. - **#21** (real tests) — how much test investment `reportbuf` deserves depends on whether it is production code or a prototype. - **#22** (shutdown loses buffered reports) is a data-loss bug only if there is data. ## Options **(a) Wire it up — the backend is part of 1.0.** Frontend gains a reporting client that POSTs periodically; `nginx.conf` gains a `location /api/` with `proxy_pass` to the backend; the two images get a compose file or equivalent so they are deployable together. This makes #19/#20/#22/#23 genuine 1.0 blockers and adds real work: a reporting client, a retention/quota policy for `DATA_DIR` (currently unbounded — `reportbuf.go:161-198` has no retention, and `backend/README.md:62` lists it as an open TODO), and an answer to what the stored data is actually for. **(b) Ship 1.0 frontend-only; the backend stays in-tree but unreleased.** Tag 1.0.0 on the SPA. The backend keeps building in CI so it does not rot, but is explicitly documented as unreleased and not deployed. #19/#20/#23 drop off the 1.0 milestone and become post-1.0. #22 (shutdown data loss) and #21 (tests) stay, at reduced priority, because they are correctness debt either way. **(c) Remove the backend from the repo.** Delete it, or move it to its own repository. Cleanest possible 1.0: the README's current "zero-dependency SPA, no backend required" framing becomes true again, and roughly a third of the open backlog evaporates. Reversible via git history. ## Recommendation **(b).** The backend is well-built and clearly intended, so deleting it (c) discards real work for a tagging convenience. But (a) is a substantial feature — a reporting client, a retention policy, and a deployment story — and none of it is written down as a requirement anywhere. Gating the first tag on inventing that scope is how 1.0 slips indefinitely. (b) lets the SPA — which is finished and works — get its tag, while keeping the backend healthy in CI until you decide what it is for. It also immediately de-risks the security posture, because an unexposed endpoint cannot be abused. If you pick (b), I would additionally suggest closing #20 as post-1.0 rather than leaving it open against the milestone, and adding an explicit line to the README stating the backend is unreleased so the next reader does not assume it is deployed. ## What I need Pick (a), (b), or (c). Assigning to you. I will re-scope the affected issues and the `1.0.0` milestone accordingly. Meanwhile I am proceeding with the work that is correct under **all three** options: #14 (lint config is invalid), #15 (dotfiles), #16 (unified gate), #17 (Dockerfile pattern), #18 (frontend security headers), #24 (documentation accuracy). None of those depend on this answer.

sneak was assigned by clawbot

2026-08-09 03:44:04 +02:00

clawbot referenced this issue

2026-08-09 03:45:07 +02:00

Backend observability: fx logs bypass slog, Identify() is dead, Sentry/Prometheus config is parsed but unwired #27

clawbot referenced this issue

2026-08-09 03:46:54 +02:00

Decision needed: repo layout does not match the canonical structure, and backend/ duplicates 7 repo-level files #30

Sign in to join this conversation.