How This Site Works

The whole site is a case study: an ASP.NET Core app prerendered to static pages, served from Cloudflare's edge, with the live data behind every app fetched by same-origin functions. This page is the map.

The architecture

Your browser Static pages (PWA) Service worker cache localStorage-first data Passkey sign-in Cloudflare edge Pages: prerendered HTML Functions: every /api/* KV: synced app data Edge cache on proxies Upstreams Michigan DNR ArcGIS NWS weather · map tiles Markets · news feeds GitHub Actions, on every push build → unit tests → smoke + accessibility → deploy → health probes

Live data is fetched by the functions, not by your browser: the upstreams above never see your request, and their API keys never leave the edge. Media is the honest exception, because proxying it would buy nothing but latency, so poster art, radar frames and album art load straight from the source. Two tools pull an OCR library from a CDN, every guide loads the Bootstrap it is teaching, and the Spotify app signs you into your own account, which only you can do. The content-security policy names those hosts and refuses the rest, with one deliberate hole: the news app may load an article image from any HTTPS host, because a headline's picture can come from anywhere.

Build and deploy

The site is a normal ASP.NET Core MVC app, but nobody runs it in production. A build script boots it, renders every route in a manifest the build checks against the catalogue, and writes the HTML to disk. GitHub Actions runs one job on a self-hosted machine, and it has to go green before anything ships. Lint, a typecheck, the unit tests over the pure logic, a second unit pass in a non-UTC timezone, and the C# side; then fourteen Playwright suites drive the built output with stubbed upstreams: a smoke pass and an axe audit that both read their route list out of the built sitemap, so a new page is covered the day it ships, a keyboard pass over the paths axe cannot see because it never presses Tab, and per-app interaction and failure-state runs. A pixel diff against checked-in baselines runs too, reporting what moved rather than blocking, because a deliberate design change moves pixels by definition. Then it deploys, waits for the production alias to flip, and runs its full check list against the live site. If those fail the deploy has already landed and the log says to roll it back from the Cloudflare dashboard - that part is a person, not a script. The version in the footer is that pipeline's stamp.

Live data without leaving home

Every app that shows live data (DNR trails and boundaries, lake depths, market prices, news) calls a Cloudflare Pages Function on this domain, which fetches the upstream, normalizes the answer, caches it at the edge, and fails open with a friendly message when the source is down. One app works the other way round on purpose: Spotify Similar Songs signs in to your own Spotify account, so that conversation is between your browser and Spotify and no token of yours ever reaches this server. The status page probes about half its roster through the same paths the apps really use, and the rest against the upstreams directly.

Your data, your device

Apps store everything in the browser first; nothing requires an account. Signing in is a passkey (WebAuthn, no passwords, verified by hand-rolled dependency-free code in a function), and it syncs a short allowlist of app data through Workers KV with last-write-wins merging. The Your Data page shows exactly what syncs, alongside everything else this site keeps in your browser.

Offline on purpose

A service worker precaches the client-side tools so they work with no network at all, keeps visited pages readable offline, and refuses to cache anything suspicious (a corporate proxy's block page can't poison an image).

36apps
6tools
8guides
v1.10.53.0this build