Jamstack — en renessanse?
Utviklere elsker forkortelser og spesielt forkortelser som gjør det enkelt å identifisere en bestemt kombinasjon av teknologi eller metoder. AJAX, LAMP, MEAN, MERN for å nevne noen. Jamstack føyer seg pent inn i denne rekken, men er forsåvidt ikke noe nytt siden det ble introdusert allerede i 2015. Det som er interessant er hvordan Jamstack har fått en liten renessanse og utviklet seg i en ny retning de siste årene.
Begrepet Jamstack er en sammenslåing av JavaScript, API og Markup. Intensjonen er en felles betegnelse på en arkitektur og strategi for optimalisering, sikring og frakobling av applikasjoner hvor målet er skalerbarhet, effektivitet og hurtighet for å nevne noe.
Jamstack-renessansen
Opprinnelig fokuserte Jamstack mye på statisk innhold og begrepet ble introdusert i en tid da feks Gatsby-rammeverket begynte å bli populært. At Jamstack nå opplever en fornyet interesse skyldes et økt fokus i IT-bransjen på sikkerhet, bærekraft, skalerbarhet og et ønske om å unngå at man blir låst inne av teknologi i store mastodont-applikasjoner, gjerne kalt “lock-in”. Dessuten er mange applikasjoner stadig mer komplekse, og vi har ofte et behov for å splitte dem opp i mer håndterbare deler.
Jamstack har gått fra å være et strikt samling av teknologi til å fokusere mer på overordnede arkitektoniske prinsipper, agnostisk teknologivalg og bedre utvikleropplevelse.
Statisk rendring
Statisk HTML genereres som en del av byggesteget, og når dette innholdet i tillegg leveres via CDN (Content Delivery Network) gir det lynrask levering til klienten eller applikasjonen som skal bruke innholdet videre, feks ved å hydrere det for videre bearbeidelse i klienten. Selv om statisk rendring alltid har vært grunnpilaren i Jamstack, så har ny teknologi de siste årene åpnet for mer avansert bruk.
Håndtering av dynamisk innhold
“Ja” i Jamstack står for JavaScript og til tross for gjengs oppfatning, så har dynamisk innhold har alltid vært en del av Jamstack-prinsippene, enten ved å hente innholdet og inkludere det som en del av byggprosessen eller tilgjengeliggjøre det via API’er og eksterne tjenester ved kjøretid. Derimot har ny teknologi og støtte i nettlesere gjort det enklere å hente inn og flette sammen dynamisk og statisk innhold som fortsatt oppleves sømløst for brukeren.
Frakobling
Ved å la frontend og backend kommunisere via felles API’er er det enklere å både skalere enkelt-applikasjoner og bytte ut teknologier uavhengig av hverandre så lenge grensesnittene i API’ene er uforandret. Headless CMS (Content Management System) er et godt eksempel på dette. Frakobling av applikasjoner i alle ledd gir som tidligere nevnt bedre fleksibilitet i tillegg til mindre risiko for at man låser seg til teknologi.
Sikkerhet
Når innhold rendres og leveres statisk, gjerne fra egen CDN, så får vi færre direkte koblinger til de bakenforliggende serverene. Dette kan være med på å redusere angrepsflaten. Når vi i tillegg har separate API’er hvor enkelte til og med er bygget kun for henting av data (altså ikke skriving), så er dette med på å redusere angrepsvektorene ytterligere.
Distribuert persistent rendring
I stedet for å rendre alt innhold statisk som en del av byggesteget utsettes rendringen av enkelte sider eller komponenter til første gang de besøkes av en bruker. Deretter caches de og leveres raskere ved neste besøk.
Dette er spesielt nyttig for store websider som har mye statisk innhold og hvor byggetiden ville blitt uforholdsmessig lang hvis man skulle rendre alle sider på én gang.
Utvikleropplevelse
Istedet for å låse seg inn i store proprietære løsninger, legger Jamstack vekt på bruk av verktøy og teknologi som har bred støtte og er lett tilgjengelig, som blant annet gjør det enklere å finne utviklere med nødvendig kompetanse.
Med frakobling får vi mer håndterbare og individuelt mindre komplekse applikasjoner som gjør det enklere for utviklere å håndtere. Med kjent teknologi følger ofte et stort fellesskap og god beste praksis som er til hjelp både for nye utviklere og for team som trenger en felles enighet og konvensjon om hvordan man jobber.
Bærekraft
Tiden hvor alt digitalt var noe immaterielt og usynlig er forbi. Stadig flere IT-bedrifter har fått øynene opp for hvordan lagring, overføring og generell håndtering av data påvirker miljøet, enten det dreier seg om økt energibruk eller utbygging av infrastruktur som følge av økt datatrafikk.
Derfor er alle grep som kan være med på å begrense energibruk ved å redusere behov for gjentakende rendring av innhold eller minimere behov for lagring og bruk av server-infrastruktur være med på å begrense fotavtrykket som IT-bransjen har på miljøet.
Ulemper
Jamstack er selvsagt ikke for alle. Med frakobling ender teamet opp med mange små applikasjoner som skal forvaltes og som krever teknisk løpende vedlikehold slik som sikkerhetspatching og oppdatering av avhengigheter.
Applikasjoner som har en stor grad av personalisering eller som i hovedsak hviler på dynamisk innhold må kanskje også tenke litt alternativt.
Åpne nettsider bør også ta SEO (Search Engine Optimization) i betraktning, for selv om Googles Web Rendering Service (WRS) kjører JavaScript på en webside for å få et mest mulig korrekt bilde av innholdet før indeksering, så er det viktig at applikasjonen er bygget på en måte som gjør at WRS får gjort jobben sin.
Tilpasset dagens behov
Oppsummert har Jamstack utviklet seg fra å fokusere på statisk rendrede sider og strikt bruk av teknologi til å være mer agnostisk med hensyn til teknologivalg. Dagens Jamstack fokuserer på arkitekturvalg som frakobling, sammensatte tjenester, serverless, tyngre bruk av CDN og utvikleropplevelse.
Som med alle andre rammeverk må team gjøre seg sin egen vurdering og kanskje også gjøre noen egne tilpassinger, men i stort har Jamstack plutselig blitt veldig relevant i hvordan vi organiserer applikasjonene våre i 2024.
Ta gjerne kontakt med oss i Systek hvis du har innspill til innlegget eller ønsker å vite hvilke muligheter det finnes for deg her :-)
Besøk oss på https://systek.no/
