Static data source for bridgic clients. No build step — a repo path is the published path.
Probing endpoints…
path in JSON is always repo-relative (e.g. static/logo.png),
never a full URL. Clients join base + path — so moving to another domain or
CDN later means changing one client constant instead of every file.api/index.json; its endpoints map lists everything
else. Clients hardcode only that one address and discover the rest from the response.github.io gets its transfers cut mid-stream on mainland-China networks
(measured: 1 failure in 3).cache-control: max-age=600, and
?v=2-style busting does not work (the query string is stripped out of the
cache key). After replacing a file in place, clients may see stale bytes for up to 10 minutes.cache: 'no-cache' to revalidate every read — the origin sends an ETag, so an
unchanged response costs a 304. This matters most on the mirror, which advertises
max-age=604800: one fallback response would otherwise sit in the local cache for
a week. The mirror's own 12h CDN cache is purged automatically on every publish.res.ok first, or res.json() throws an opaque parse error.Fallbacks for when the primary origin is unreachable. Split by resource type, because JSON and images need opposite things and no single jsDelivr endpoint gives both. Append any repo-relative path.
JSON — purgeable, so API reads stay fresh:
Images — serves bytes directly instead of redirecting to raw:
jsDelivr's purge API only clears cdn and fastly, not gcore,
so a replaced image can be up to 12h stale on the asset mirror — rename the file rather than
overwriting it when that matters. To pin an exact version, replace @main with a commit
sha; that URL is permanently immutable.
Full implementation in examples/staticBridgicClient.ts, ready to copy into apps/electron/src/renderer/lib/.