Overview

What it is

The Tools app is a standalone member-directory utility for staff at tunnels. It exists for one specific failure mode: when the main WWW app is down, tunnel staff still need to verify membership, currency status, and recent logbook entries to safely check flyers in. The Tools app does that one job and nothing else — it has no auth UI, no payments, no member self-service. Just search + lookup.

Repo path: tools/.

Why it exists (the disaster-recovery story)

There was a production incident where the main www site went down during operating hours. Staff at the tunnels couldn’t check anyone in because they couldn’t verify membership — and tunnel operations stop when staff can’t safely confirm a flyer is current. The Tools app was built as a deliberately-decoupled fallback:

Different deployment platform (Cloudflare Pages + Workers, not DigitalOcean App Platform) — so a DO outage doesn’t take it down.
Different runtime (Cloudflare Workers, no Node.js server) — so a Node-side regression in api or www doesn’t break it.
Direct DB access (Workers query MySQL directly, no api/ layer) — so an api outage doesn’t break it.
Tiny attack surface (read-only, no auth flow, gated by Cloudflare Access at the edge) — minimal exposure for a tool that can stay live during incidents.

In short: it’s an independent path to the same data, deliberately overlapping with nothing the main platform depends on. If everything else is on fire, Tools keeps working.

Architecture

Technology stack

Backend (tools/api/) — Cloudflare Worker (TypeScript), MySQL queries to the production DB cluster. Deployed via wrangler deploy.
Frontend (tools/app/) — React 18 SPA built with Vite, deployed to Cloudflare Pages. No SSR.
Auth — Cloudflare Access in front of both routes. No application- level login screen.
Observability — Sentry on the worker; Web Vitals on the frontend.

Layout


tools/
├── api/              Cloudflare Worker backend
│   ├── src/index.ts          Worker entry point
│   ├── src/routes/api.ts     Route handlers
│   ├── src/db/mysql.ts       Direct DB queries
│   ├── wrangler.toml         Worker config
│   └── .dev.vars.example     Sample local credentials
└── app/              React SPA frontend
    ├── src/main.tsx
    ├── src/App.tsx
    ├── src/components/
    ├── src/hooks/
    └── vite.config.ts

Local dev


cd tools
npm run install:all
 
# DB credentials for the worker
cp api/.dev.vars.example api/.dev.vars
# Edit api/.dev.vars
 
npm run dev
# API → http://localhost:8787
# App → http://localhost:3000

The worker talks to the production DB by default — Tools has no local DB mode because it’s a read-only utility and the whole point is to verify against the source of truth. Be careful about query patterns on a local dev session.

What Tools intentionally does not do

No member sign-up or profile editing.
No payment processing.
No safety-training workflow.
No bookings.
No instructor / coach / military views beyond read-only currency.

All of those live in WWW and the API. The discipline of “this one tool does one thing” is what keeps it deployable independently.

Features (read-only)

Search by email, username, full name, or member ID.
Member details — join date, home tunnel, payment status, role, currency status across all disciplines.
Logbook — every entry, plus instructor / trainer / coach / military / flyer currency views.
Health check — the worker exposes a /health endpoint that Cloudflare can probe.