Van Strava naar een statische website
Hoe maandelijkse sportdata een plek krijgt op een snelle statische site, zonder van ieder bezoek een API-verzoek te maken.
Een statische website en actuele sportdata lijken op het eerste gezicht niet goed bij elkaar te passen. De ene wordt vooraf gebouwd en verandert pas bij een nieuwe release. De andere leeft in een externe API en groeit na iedere activiteit.
Toch hoeft actuele data niet automatisch live data te betekenen.
Eerst bepalen wat actueel genoeg is
Voor de cijfers op deze site maakt het weinig uit of een hardloopsessie binnen vijf seconden of aan het begin van de volgende maand zichtbaar wordt. Het zijn geen wedstrijdresultaten en niemand gebruikt ze om een operationele beslissing te nemen. Ze geven vooral een klein inkijkje in wat er buiten code gebeurt.
Daarom haalt een geplande GitHub Action één keer per maand de activiteiten van het lopende jaar op. Het script telt afstand, beweegtijd, hoogtemeters en het aantal activiteiten bij elkaar op. Alleen die totalen worden opgeslagen in de repository.
Routes, locaties en individuele activiteiten verdwijnen meteen weer uit het proces.
De beste verversfrequentie is niet de snelste, maar de frequentie die past bij de betekenis van de data.
OAuth is meer dan een eenmalige sleutel
De koppeling gebruikt een Strava-app met een client-id, client-secret en refresh token. Die waarden staan als versleutelde repository secrets in GitHub en komen niet in de gebouwde website terecht.
Strava kan bij het vernieuwen van de toegang ook een nieuw refresh token teruggeven. De workflow moet dat token direct veilig terugschrijven, anders werkt de volgende synchronisatie met een inmiddels ongeldig exemplaar. Dat kleine detail is precies het soort probleem dat bij de eerste succesvolle API-call nog onzichtbaar blijft.
De updater faalt bewust hard als de Strava-koppeling vereist is maar niet werkt. Geen stilletjes terugvallen op verzonnen of verouderde cijfers: liever geen nieuwe release dan data die betrouwbaar oogt maar dat niet is.
Data wordt onderdeel van de build
Na de synchronisatie schrijft het script een klein JSON-bestand. De normale Astro-build leest dat bestand alsof het gewone site-inhoud is. Vervolgens draaien dezelfde typechecks en buildcontroles als bij iedere andere wijziging.
Pas als die controles slagen, commit de workflow de nieuwe totalen. Cloudflare ziet de commit, bouwt de statische site opnieuw en rolt de versie uit. Voor bezoekers blijft het resultaat daardoor eenvoudig: kant-en-klare HTML, zonder API-sleutels, wachttijd of afhankelijkheid van Strava tijdens het openen van de pagina.
Een kleine koppeling met een duidelijke grens
Het systeem is niet realtime en probeert dat ook niet te zijn. Het doet één taak op een voorspelbaar moment, bewaart alleen wat de site nodig heeft en gebruikt de bestaande deployketen.
Juist die beperking maakt de koppeling prettig. Als Strava tijdelijk niet beschikbaar is, blijft de huidige website gewoon werken. Als de updater stukloopt, is dat zichtbaar in GitHub. En als ik ooit besluit de telemetry te verwijderen, blijft er geen database met persoonlijke activiteiten achter.
Voor vier speelse cijfers is dat misschien behoorlijk veel aandacht. Maar kleine systemen zijn een goede plek om grote principes serieus te nemen.