Jeg liker Jamstack fordi det lar meg fokusere på å utvikle og distribuere nettsider kjapt og effektivt. Veien er kort fra idé, gjennom kode og til sluttbrukeren.

I Jamstack distribuerer man frontend gjennom det som kalles et Content Delivery Network (CDN). Dette gjør at det er mulig å lage og distribuere nettsider uten å tenke så mye på infrastruktur.

Det er digg for en frontendutvikler.

CDN

Et innholdsleveringsnettverk (CDN) er et nettverk som består av flere servere som er geografisk spredt ut. Sammen står de for å gi kjapp og tilgjengelig levering av internettinnhold.

Innholdet blir gjerne lagret på én eller flere sentrale servere, før det blir distribuert til flere servere på utkanten, nærere forbrukeren.

Ved å lagre innehold på servere nærme brukeren bidrar dette nettverket til å øke tilgjengeligheten av innhold. Det er nære brukeren og avlaster eventuelle sentrale servere.

I en verden hvor veldig mye av nettrafikk skjer via mobilen, er hastigheten og tilgjengeligheten man får fra et innholdsnettverk gull verdt.

Innholdet som serveres over nettverket må derimot være statisk. Dette setter begrensninger for hvilke type innhold som kan serveres.

Bruken av et innholdsnettverk innebærer at frontend må bygges til statiske (ikke-dynamiske) nettsider før distribusjon.

Jamstack

Jamstack står dermed i kontrast til nettsider som dynamisk genereres på en server.

Et klassisk eksempel på nettsider som dynamisk genereres på en server, er nettsider bygget i Wordpress. Her står PHP for genereringen av det brukeren ser, og dette gjøres på en server før filene sendes til brukeren. Den dynamiske genereringen gjøres for hver bruker som besøker nettsiden.

I Jamstack blir den dynamiske genereringen av brukerinnhold gjort gjennom Javascript og API-kall. Dette betyr at dynamisk innhold blir skapt i browseren, og gjør at man ikke er begrenset av en sentral server eller annen infrastruktur for å håndtere brukertrafikk.

Det er dette som gir det navnet Jamstack: JAM i Jamstack, står for henholdsvis Javascript, APIer og Markup.

Javascript

Javascript er det som står for det dynamiske i nettsiden.

I dag har vi rammeverk som React, Vue og Angular som gjør at dynamisk innhold enkelt kan genereres i browser.

En server for å håndtere dynamisk innhold trengs ikke.

API

Alle har et API i dag.

Jamstack benytter seg av dette. I Jamstack avkobler man frontend fra backend ved at det som trenger mer ressurser, annet innhold eller krever innhold fra en database, gjøres via API-kall.

Dette gjør også at man kanskje lettere benytter seg av andre APIer. Man kan for eksempel koble seg opp til OAuth for brukerhåndtering, Stripe for betalingshåndtering, eller Google Analytics for bruksanalyse.

Dette gjør at Gatsby har påpekt at man kan snakke om et Mesh-nettverk av innhold.

Jamstack gjør det enkelt å benytte seg av den API-økonomien som nå eksisterer.

Tilbydere som AWS, Azure og Google Cloud har også gjort det enkelt å sette opp egne mikrotjenester (Lambda/Functions), og man kan dermed enkelt skape og koble seg opp til sine egne API hvor det er ønskelig.

Jamstack minner dermed om apputvikling for mobiler. En mobil-app kan ikke være avhengig av en sentral server for dynamisk innhold. Det dynamiske skjer på mobiltelefonen, og appen kobler seg kanskje opp mot et eksternt API.

Det samme gjelder Jamstack på nett.

Markup

Markup betegner metoden som brukes for å skape malene til nettsidene. Malene blir så brukt i en statisk side-generator (SSG) eller et annet byggeverktøy til å skape innholdet som blir servert over CDN.

Markup-delen i JAM påpeker dermed at det er forhåndsoptimaliserte statiske filer som serveres over et innholdsnettverk.

I Jamstack er gjerne byggingen av filene sentrert rundt en Git-arbeidsflyt.

Det betyr gjerne at man må sette opp sin egen CI/CD. For simonsier.no har jeg satt det opp via AWS sine egne byggeverktøy (CodePipeline) og distribuert den via S3 og innholdsnettverket CloudFront.

Tilbydere som Netlify og Google Firebase (som jeg bruker for ordsky.no sammen med Github actions) gjør det enkelt å sette opp en test og deploy pipeline enten via egne verktøy eller ved å koble sammen med Github. Github og Gitlab Pages er også enkle verktøy som gjør det enkelt å distribuere nettsiden via et enkelt git push.

AWS Well Architected Framework

Gjennom å avkoble frontend fra backend og å benytte seg av innholdsnettverk, blir Jamstack en god webutviklingsarkitektur.

For å illustere kan vi se på Jamstack gjennom AWS sitt rammeverk for å vurdere arkitekturer.

AWS sitt Well Architected Framework er et rammeverk for å hjelpe til å bygge gode arkitekturer på AWS. Det er også et rammeverk som det er nyttig å bruke på generell arkitektur.

I følge dette rammeverket kan en godt strukturert arkitektur bedømmes ut ifra følgende fem pillarer:

• Sikkerhet
• Pålitelighet
• Kostnadsoptimalisering
• Operasjonell dyktighet
• Ytelseseffektivitet

Sikkerhet

Sikkerhetspillaren handler om hvordan du beskytter informasjon og systemer.

Typiske eksempler på hva som anngår sikkerhet er kryptering (av data i ro og under transport), monitorering og håndtering av identiteter.

Siden Jamstack ikke består av en sentral server, er denne type sikkerhetsproblematikk primært håndtert av de som tilbyr APIene man bruker.

Sikkerhet er dermed noe som ikke kommer automatisk i en Jamstack-arkitektur, men er avhengig av hvordan det impleneteres.

Mangelen på server gjør likevel at det er en del sikkerhetsproblematikk man slipper å tenke på.

Pålitelighet

Pålitelighetspillaren handler om hvordan systemet håndterer svikt i infrastruktur eller tjenester.

I praksis handler det ofte om å ikke ha ett enkelt feilpunkt (Single Point of Failure) som kan bringe ned hele systemet. Dette betyr å ha en arkitektur som er "loosely coupled", det vil si, komponenter som er koblet fra hverandre.

Tradisjonelt skapes slik pålitelighet gjennom å bruke køsystemer, lastbalanserere og så videre.

Siden man i en Jamstack avkobler frontend fra backend øker man påliteligheten til systemet.

Hvis man i tillegg benytter seg av et nettverk av APIer øker gjerne det også påliteligheten, gjennom å spre risiko. Det avhenger da av at man kobler seg til APIene på en måte som ikke ødelegger funksjonaliteten til nettsiden om de skulle ha problemer.

Kostnadsoptimalisering

Ta hensyn til kostnad i arkutekturen. Unngå unødvendige kostnader eller dårlig ressursbruk.

Siden man ikke benytter servere for å distribuere nettsiden, slipper man kostnadene som det innebærer. Innholdsnettverk er betydelig billigere enn en serverpark.

Operasjonell dyktighet

Denne pillaren handler om hvordan kjøre og monitorere systemet på en måte som øker verdien til systemet. Faktorer som bedriftens behov og håndtering av risko er viktig her.

I Jamstack så er arbeidsflyten senterert rundt git og automatiserte deployments. Dette øker den operasjonelle dyktigheten til arkitekturen. Arbeidsflytten tilrettelegger for atomiserte deployments av nettsiden, som øker hastigheten for å få ut endringer.

Jamstack gjør det lett å få ut kontinuerlige forbedringer på nettsiden og bidrar til å øke verdien til systemet.

Yteleseseffektivitet

Ytelseseffektivitet handler om å bruke (computing) ressurser effektivt. Monitorering er viktig, men også kunnskap om hva som finnes.

Å bruke innholdsnettverk for å distribuere nettsider er effektiv ressursbruk. Man slipper å ha ubrukte serverressurser og nettsiden er uendelig skalerbar.

Å benytte seg av API-økonomien kan også være med på å maksimere ytelse. Ved å benytte seg av tjenester som er godt utprøvd er man ofte sikret en kvalitet man slipper å skape selv.

En webutviklings arkitektur

I Jamstack er HTML forhåndsbygd til statiske filer, nettsidene er distribuert gjennom et globalt CDN, og oppgaver som tidligere ble gjort på en server er nå gjort gjennom APIer og mikrotjenester.

AWS sitt rammeverk for god arkitektur viser også at jeg kan være trygg i å bruke denne arkitekturen.

Den git-sentrerte arbeidsflyten og avkoblingen fra en bakend gjør at jeg som frontendutvikler kan fokusere på det jeg liker: å lage sluttprodukter som skaper merverdi.

Jamstack gjør det lett å lansere skalerbare nettsider uten at jeg trenger å tenke på infrastruktur. Om jeg likevel bygger et system som er avhengig av en backend, så vet jeg at Jamstack burde være en del av arkitekturen.