Folk tenker først og fremst på CDN-er, også kjent som Content Delivery Networks, hvis det er behov for å kunne distribuere større datamengder til større antall brukere.
Men CDN-er kan også brukes for å slippe å knote med mellomlagring også i ens egen private småskalabruk.
Værdata fra Yr
I mitt tilfelle var det snakk om værdata fra Yr, som er tilgjengelige via et åpent API. Selv om data er åpne, gjelder det et sett av regler for hvordan man skal opptre for å kunne bruke API.
Som en advokat er jeg naturligvis opptatt av å overholde alle slike regler. Og reglene går i korthet ut på følgende:
- Man må indentifisere seg
- Man må ikke forårsake unødvendig trafikk
- Man må ikke overbelaste servere
I tillegg må man ved bruk av data navngi datakilden.
'Rutinemessig oppgradering' endte med at CMS-et til store, norske nettaviser gikk ned i over to timer
Skript, eller CDN
Identifikasjon skjer enten ved å sette User-Agent eller Referer-header, og unødvendig trafikk unngår man ved å mellomlagre svarene lokalt i samsvar med det som Expires-headeren tilsier.
Ingenting av dette er vanskelig, men hvis man har noen shell-skripter som kombinerer curl og jq, så blir iallfall mellomlagringen en kompliserende faktor.
Man kan selvsagt skripte seg frem til en løsning.
Eller man kan bruke CDN.
«Dette har fungert kjempebra!»
Ganske deilig
Min personlige favoritt er Bunny CDN fra Slovenia. Jeg tok dem i bruk i januar 2022 for API for uptime.is, fordi data fra API egnet seg meget godt for mellomlagring.
Så jeg tenkte: «Hvorfor ikke bruke Bunny CDN for å cache data fra Yr?»
Dette har fungert kjempebra!
curl kan brukes på den vanlige måten uten å tenke på å sette identifiserende User-Agent eller knote med caching, for alt sånt tar Bunny CDN seg av nå. Alle forespørsler til Yrs vær-API får et identifiserende User-Agent, og alle svar blir automatisk mellomlagret hos Bunny.
Det er ganske deilig!
Hadde det vært snakk om store datamengder, ville jeg også ha tenkt på å mellomlagre data lokalt for å spare tid og båndbredde, men altså ikke for JSON.
