En snabbare och säkrare webbplats med JAMstack

JAMstack är en samling teknologier (JavaScript, API:er och Markup) som används för att bygga dynamiska webbplatser. Här berättar vi mer om vad det är och hur det kan hjälpa din webbplats att bli både snabbare, säkrare och skalbar.

Vad är JAMstack?

JAMstack är namnet på en specifik arkitektur för att bygga webbplatser. JAM står för JavaScript, API och Markup. En stack är helt enkelt en kombination av flera tekniker. Du har kanske hört ordet teknikstack som benämning för en samling tekniker som fungerar bra ihop? JAMstack är en sådan teknikstack.

Markup i form av HTML kom 1991, JavaScript kom 1995 och API:er har funnits sedan tidigt 50-tal även om de då såg väldigt annorlunda ut. Så varför denna hype kring Jamstack? Det känns snarare som att någon fått en släng av nostalgi och helt plötsligt vill bygga webbar som man gjorde på 90-talet. Och faktum är att det inte är en så dum observation! Syftet med JAMstack är nämligen att öka prestanda, säkerhet, skalbarhet och robusthet genom att göra saker lite mindre komplicerade med färre rörliga delar.

I viss mening var saker lite mindre komplicerade förr. Samtidigt var tekniken väldigt outvecklad. Idag är den inte det. Så även om man använder en gammal princip för att bygga webbplatser så har man idag fler och mycket mer avancerade verktyg som gör att man kan automatisera mycket av det arbete som tidigare gjordes manuellt. Det är en starkt bidragande orsak till att tekniken återigen blivit aktuell.

Så vad är egentligen JAMstack?

Om du nöjer dig med den korta versionen så kommer den här:

"Att bygga sidor med en static site generator, serva dem via ett CDN och använda JavaScript och API:er för dynamiskt innehåll."

Men om du är lite mer nyfiken än så, fortsätt gärna att läsa.

Fördelarna med JAMstack – vi listar fyra stycken

1.    Ökad prestanda

På en webbplats som ligger i ett traditionellt CMS, t.ex. Umbraco, Episerver eller Wordpress, så genereras sidorna av servern i det ögonblick de efterfrågas av besökarna. Det tar inte speciellt lång tid - vi pratar millisekunder - men webbservern måste fortfarande hämta data från en databas och generera en sida med denna data och en sidmall som utgångspunkt. Det tar längre tid än att bara serva en redan färdig fil. Och om man måste generera sidan dynamiskt så behöver man även en server som kan exekvera kod i realtid, en databas där man kan lagra data och så vidare. Allt det har man skalat bort (eller snarare flyttat undan) i JAMstack. Man servar redan färdiga filer från webbservrar som inte bygger några sidor eller exekverar någon kod alls.

Det betyder inte att man inte måste generera sidor om man använder Jamstack, bara att de genereras i förväg i samband med att koden sparas och byggs. Därmed finns de färdiga och kan servas direkt när de efterfrågas.

Alltså: en sida i JAMstack byggs i förväg när koden sparas och byggs, inte i det ögonblick en användare efterfrågar den.

2.    Enklare, snabbare och billigare hosting

I och med att vi tar bort mycket av komplexiteten på serversidan genom att serva statiska sidor (HTML-filer) så kan vi använda helt andra hostinglösningar. Istället för at lägga sidorna på en dynamisk webbserver hos ett webbhotell så kan man lägga dem direkt i ett CDN (Content Delivery Network) tillsammans med andra statiska resurser såsom bilder, stilmallar och scriptfiler. Ett CDN är inte bara en betydligt billigare hostinglösning, det är dessutom mycket snabbare och tillförlitligare. (Om du vill veta varför, kolla gärna in vår andra artikel som handlar om CDN.)

3.    Säkrare

JAMstack är allmänt betraktad som en säkrare arkitektur än webbplatser byggda på sidor som genereras av dynamiska script som körs på serversidan. Argumentet bakom det är att man har tagit bort mycket av "de rörliga delarna" genom att serva enkla filer och därmed reducerat antalet potentiella säkerhetshål som en komplex arkitektur kan exponera.

Till viss del är det sant, men så fort du introducerar dynamiska funktioner baserat på användarinteraktion så kommer du också öppna upp för potentiella säkerhetshål. Och dynamiska funktioner kan finnas även i JAMstack, även om de exponeras via ett API istället för direkt i scriptade sidor. Så bara en arkitektur i sig kan inte ensam göra en webbplats säker. Det är snarare en medvetenhet och kunskap hos de som utvecklar webbplatsen i kombination med en teknisk arkitektur som står som garant för säkra webbplatser.

4.    Skalbarhet

Om du har dina webbsidor och andra filer i ett CDN så har du skalbarhet per default eftersom CDN är byggda just för att hantera stora variationer i mängden trafik och har implementerat tekniker för att hantera just detta med robust infrastruktur, data som hostas nära användaren rent fysiskt (i samma stad, land eller världsdel) och mycket fokus på cachning av data. Med en traditionell webbplats så kanske man måste gå in och skruva upp prestandan i förväg på servern om man förväntar sig hög belastning. Det behöver man inte tänka på om man har sin hosting på ett CDN.

Hur skapar man dynamiska funktioner?

Hittills har vi pratat mycket om själva sidorna, dvs. M:et i JAMstack (Markup). Vi har konstaterat att det är statiska HTML-sidor som genereras i samband med att koden sparas och byggs. Men om sidorna redan är genererade på förhand, hur kan man då få till dynamiska funktioner som användarna kan interagera med? Om du t ex har en sida som listar produkter så vill användaren kanske sortera dessa på pris eller filtrera dem efter märke eller färg. På en statisk sida är detta omöjligt. Det är här J:et (JavaScript) och A:et (API) kommer in i bilden.

Även om en HTML-sida är statisk så kan den fortfarande ha JavaScript-filer kopplade till sig. Scripten kan i sin tur göra allt som behövs för att implementera olika former av dynamisk funktionalitet: hantera användarinteraktion, generera dynamisk markup (t.ex. en sorterad produktlista), hämta och spara data via ett API osv.

”Om sidorna är statiska, hur får man till dynamiska funktioner?”

Vi nämnde tidigare att man hade flyttat undan dynamisk funktionalitet och datalagring från den server som servar själva webbsidorna i JAMstack och det stämmer. Men det betyder inte att man klarar sig utan det. Man kommer fortfarande behöva hämta och spara data. All sådan funktionalitet har man flyttat ut till API:er. Så istället för att data tas emot av samma server som servar webbsidorna så skickas den via ett API från en applikationsserver som bara exponerar ett API. Där kan man ha både affärslogik (i form av exekverbar kod på serversidan) och datalagring i form av databaser. Och detta är viktigt att förstå: man kommer inte på något magiskt sätt att klara sig undan teknik på serversidan bara för att man använder Jamstack, man har bara lyft ut den till ett separat API.

Vad behövs för JAMstack?

Det kanske låter som att Jamstack är namnet på en produkt eller en specifik teknisk plattform, men det är det inte. Det är bara en arkitektur. Man kan alltså använda en massa olika kombinationer av mer specifika plattformar, ramverk och tjänster för att bygga en webb med JAMstack. Men man kommer fortfarande behöva följande kategorier av plattformar:

• En site generator
  Site generator är den plattform som ansvarar för att generera själva HTML-sidorna som utgör webbplatsen. Det den gör är ungefär vad en modern webbserver gör: den tar innehåll och sidmallar och smackar ihop det till sidor.
• Ett javascriptramverk
  Vill man ha någon form av interaktivitet så behöver man JavaScript. Det går såklart utmärkt att utveckla denna funktionalitet i ren JavaScript utan något ramverk som stöd, men det kommer att bli en utmaning och ta tid. Därför brukar man använda någon form av javascriptramverk, t.ex. React eller Vue. I många fall hänger site generator och javascriptramverk ihop under ett samlingsnamn, t.ex. Next.js eller Gatsby.js, som är två av de största plattformarna.
• Förmodligen ett headless CMS
  Den roll som ett headless CMS fyller i Jamstack är som API. Det är det ställe där du laddar upp dina bilder, skriver texter och gör inställningar. Detta innehåll exponeras sedan via ett API som kan konsumeras dynamiskt med hjälp av JavaScript eller direkt när sidorna byggs och bli en del av sidorna på webbplatsen.

Utöver detta finns det två andra kategorier av plattformar/verktyg som troligtvis behövs:

• Lagring och versionshantering av källkod (ett repository)
• En lösning för byggen och deploy

Dessa är dock inte unika för just Jamstack utan behövs oavsett vilken typ av arkitektur man väljer för sin webb. Ibland är det egna produkter, ibland har man bakat ihop flera olika produktkategorier i samma plattform, t.ex. att man både kan hantera innehåll (CMS), bygga kod och publicera det ut till ett CDN.

Två exempel på att använda API:er – på olika sätt

Normalt när man pratar API:er så tänker man att det är ett ställe där man kan hämta och spara data dynamiskt, oftast initierat av någon form av användarinteraktion. Det kan t ex vara i ett sökfält; användaren skriver något i fältet, så frågas API:t och om det finns några sökträffar som matchas så får man tillbaka ett resultat. Det är ett exempel på dynamisk användning av ett API.

Men om man använder en site generator så kan man även använda API:t statiskt, i samband med att man genererar sidorna. Det är framför allt användbart när det innehåll man hämtar från API:t inte är beroende av någon form av användarinteraktion, dvs att det är samma innehåll hela tiden oavsett vad användaren gör på sidan.

Säg till exempel att du i ditt headless CMS skapar en sida. Du skriver en rubrik, laddar upp en bild, klistrar in en text som du har skrivit och lägger till en handfull länkar. Allt detta är innehåll som inte kommer att påverkas av användarinteraktion eftersom det alltid ligger fast på sidan. Då känns det onödigt att behöva hämta det dynamiskt varje gång en användare besöker din sida. Så istället för att hämta det varje gång så ser man till att innehållet hämtas en enda gång i samband med att sidan byggs. Sedan ligger det där tills någon går in och ändrar det. Då byggs sidan om igen och du får en ny statisk sida.

Så en webb byggd med en static generator är både statisk och dynamisk samtidigt. Filerna som servas är statiska, men deras innehåll kan vara mer eller mindre dynamiskt beroende på hur man väljer att använda sina API:er.

När är JAMstack inte lämpligt?

Det finns ett tydligt scenario där JAMstack är en direkt olämplig arkitektur och det är när man har en enorm webbplats. Med enorm menar vi en webb med 100 000 eller fler sidor. Att generera och lagra alla dessa sidor som statiska sidor kan då bli ett problem i sig eftersom det tar mycket resurser i anspråk, både i termer av tid och processorkraft. Då är det förmodligen smartare att titta på en arkitektur som är databasdriven.

”JAMstack är inte lämpligt för enorma webbplatser”

Man kan även fundera på om JAMstack är lämpligt om man har en webbplats där mycket av innehållet ligger bakom inloggning och i hög grad är anpassat till den individuelle användaren. Då faller lite av poängen med att generera statiska sidor eftersom innehållet per definition måste vara dynamiskt just för att det är individuellt. Det går visserligen fortfarande att sätta upp ett statiskt ramverk kring webbplatsen och använda API:er för att hämta all dynamisk information, men det är inte ett scenario där Jamstack verkligen sticker ut.

Avslutningsvis

Ju mer man läser och lär sig om JAMstack, desto mer inser man hur sammankopplat det är med CDN. Det är i kombinationen mellan statiska filer och ett CDN:s förmåga att serva dessa snabbt, billigt och säkert som JAMstacks storhet ligger. Det finns också något tilltalande i att gå tillbaka till det enkla och robusta i statiska filer och samtidigt kunna erbjuda en modern och tekniskt avancerad användarupplevelse. Som vi kunde konstatera är det dock fel att tro att en webb byggd på JAMstack helt saknar dynamisk serverteknik, men man har gjort det mycket tydligare vad som är frontend och vad som är backend genom uppdelningen mellan filer och API:er.

Läs även