En artikel skal kunne læses, også når maskinen, der producerede den, er slukket.
Det er et grundprincip i den måde, vi bygger hjemmesider på. Vi redigerer, bearbejder og publicerer fra et separat system. Den offentlige hjemmeside består af færdige filer, som kan leveres direkte til læseren.
Dermed bliver læsningen uafhængig af redaktionssystemet, statistikbehandlingen og de programmer, der producerer indholdet. De systemer skal fungere, når vi bruger dem. Hjemmesiden skal fungere hele tiden.
For magasiner, blogs, virksomhedssider, dokumentation, arkiver og mange kataloger mener vi, at det er et stærkt udgangspunkt: en lille offentlig angrebsflade, få afhængigheder under besøget og en drift, der er lettere at overskue.
Sikkerhed gennem færre angrebsmuligheder
På den offentlige hjemmeside er der ingen CMS-administration, ingen databaseforbindelse og ingen PHP- eller Node.js-applikation, som skal behandle læserens forespørgsel. Filhosting som Amazon S3 leverer de færdige filer. JavaScript kan stadig køre i læserens browser. AWS’ beskrivelse af statisk hosting
Det fjerner en stor kategori af angreb mod vores egen serverkode. Et sårbart plugin kan ikke give adgang til en serverproces, hvis pluginet og processen slet ikke findes i den offentlige løsning.
Der er stadig noget at beskytte. Adgangen til publicering, hostingkontoen, domænet og produktionsmiljøet har stor betydning. En angriber med skriverettigheder kan også udskifte filer og lægge skadelig JavaScript ind. Derfor er "uhackbar" et for stort løfte.
Den præcise fordel er til gengæld betydelig: Vi fjerner angrebsmuligheder ved at fjerne offentligt tilgængelige programdele.
I en traditionel CMS-installation omfatter vedligeholdelsen blandt andet selve systemet, plugins og temaer. WordPress’ egen sikkerhedsvejledning understreger behovet for at holde disse dele opdaterede og fjerne ubrugte plugins. Det arbejde følger med den arkitektur. WordPress’ sikkerhedsvejledning
Arbejdet bliver gjort før besøget
Når tusind mennesker læser den samme artikel, kan de modtage den samme færdige fil.
Med et CDN kan kopier ligge tæt på læserne og leveres uden at hente indholdet fra oprindelsesstedet ved hvert besøg. Det er en veletableret måde at håndtere stor trafik på. Sådan fungerer CloudFront
Vi har stadig udgifter til trafik, lagring og forespørgsler. Gevinsten er, at hvert besøg kræver meget lidt arbejde i vores eget system. En populær artikel skaber ingen kø af databaseforespørgsler hos os.
WordPress og andre dynamiske systemer kan også levere færdige sider gennem caching. WordPress anbefaler selv denne teknik som en væsentlig optimering. Vores valg er at gøre den færdige publicering til selve fundamentet for hjemmesiden. WordPress om caching
Interaktion kan behandles i portioner
Et statisk publiceret site kan godt have interaktion.
Læseren kan give en artikel hjerter, deltage i en uformel afstemning eller sende et lille signal om, hvad vedkommende bruger. Signalet bliver opsamlet. Senere behandler vi hændelserne og publicerer nye resultater.
Det giver os frihed til at definere reglerne i behandlingen:
- Alle hjerter tæller.
- Højst ti hjerter pr. bruger pr. dag tæller.
- Gentagelser bliver sorteret fra.
- Resultater bliver fordelt på artikler, perioder eller relevante segmenter.
En regel pr. bruger kræver selvfølgelig en identifikation, der er god nok til formålet. Et anonymt browser-id kan understøtte en uformel begrænsning; en bindende afstemning kræver stærkere kontrol.
Når vi bevarer det nødvendige datagrundlag, kan vi også rette beregningen og køre den igen. Reglerne behøver dermed ikke være låst til den kode, der kørte, da læseren trykkede.
Trafikloggens kvalitet sætter grænsen for, hvad vi kan love. Hvis opsamlingen eksempelvis bygger på S3’s almindelige adgangslog, er hverken fuldstændighed eller leveringstid garanteret. Den egner sig derfor til opgørelser, hvor den usikkerhed er acceptabel. Handlinger, der kræver sikker registrering, får en dedikeret modtagelse. AWS om loglevering
En fejl kan få lov at vente på os
Hvis statistikbehandlingen stopper, bliver statistikken ældre. Artiklerne kan stadig læses.
Det er en af arkitekturens vigtigste egenskaber. Vi har adskilt systemerne, så en fejl i baggrundsarbejdet får et begrænset virkefelt.
Vi kan undersøge fejlen, rette programmet og behandle de bevarede data igen. Det giver en anden arbejdsro end en fejl, der samtidig forhindrer besøgende i at åbne hjemmesiden.
Næste naturlige skridt er at gøre behandlingsmaskinen udskiftelig. Logfiler, nødvendige mellemresultater og oplysninger om gennemførte kørsler kan ligge i et fælles, beskyttet lager. En autoriseret maskine kan derefter hente data, beregne og publicere.
Den maskine kan være en lille VPS med lukket indgående adgang og administration gennem en kontrolleret kanal. Den skal stadig vedligeholdes, men behøver ingen offentlig webapplikation. Med reproducerbare kørsler og styr på, hvem der publicerer hvornår, kan en anden maskine overtage arbejdet.
Det gør den lokale computer til én mulig udfører. Hjemmesidens opdateringer behøver ikke afhænge af, at netop den er tændt.
Vi vælger opdateringsrytmen efter indholdet
Et magasin med essays, interviews og anmeldelser har andre tidskrav end et system til handel med den sidste ledige billet.
For magasinet kan en kontrolleret publicering være præcis den rigtige arbejdsgang. Redaktionen færdiggør en artikel, kontrollerer resultatet og sender den ud. Besøgstal og reaktioner følger deres egen rytme.
Statisk publicering kan også automatiseres til hurtige opdateringer. Forsinkelsen afhænger af produktion, publicering og cache. Den er et konkret designvalg, og indhold behøver ikke vente på næste statistikberegning.
Vi vælger derfor ud fra to spørgsmål: Hvor hurtigt skal en ændring være synlig? Og hvad sker der, hvis en bruger handler på en lidt ældre oplysning?
Når svaret tillader forskudte opdateringer, får vi mulighed for at forenkle driften markant.
Vores dogme: Hver levende afhængighed skal gøre sig fortjent til sin plads
Der findes flere velbegrundede udgangspunkter for et website.
CMS-platformen prioriterer redaktionel selvbetjening og et stort udvalg af funktioner. Applikationsplatformen prioriterer løbende samspil, brugertilstand og hurtige ændringer. Vores udgangspunkt prioriterer den færdige publicering og dens evne til at blive ved med at fungere.
De valg kan kombineres. Et CMS kan producere statiske filer. En statisk hjemmeside kan bruge en dedikeret formularserver. En enkelt funktion kan få en dynamisk tjeneste, når dens behov berettiger det.
Vores krav er, at hver sådan afhængighed skal levere en konkret værdi.
For de sites, der passer til modellen, forventer vi en lav samlet driftsomkostning. Regnestykket omfatter også udvikling og vedligeholdelse af vores egne værktøjer. Gevinsten vokser, når det samme gennemprøvede publicerings- og behandlingssystem kan bruges på tværs af mange sites.
Vi vægter sikkerhed, enkel levering og overskuelig fejlhåndtering højt. Vi accepterer en aftalt forsinkelse, hvor den har lille betydning for brugeren.
En færdig artikel skal kunne blive liggende og gøre sit arbejde. Også mens vi laver noget andet.