september 27, 2017
1. Problemet med CMS
Den första frågan man bör ställa när man bygger en ny webbplats är "Kommer vi att kunna byta ut den?". Det är obekvämt att behöva tänka på att den nya fina webben man bygger någon gång kommer att bli gammal, men det innebär tyvärr inte att det inte kommer att hända. Det är när man inte tänker på det som man skapar svårutbytbara lösningar som kräver separata migrationsprojekt för att komma ur.
Men tänk om man kunde byta ut delar allteftersom istället för att ha stora migrationsprojekt var femte till tionde år?
Inom systemutveckling har man länge pratat om mikrotjänster som ett sätt att skapa förändringsbarhet. Genom att bygga små oberoende tjänster som pratar med varandra via tydliga gränssnitt blir det möjligt att ändra, lägga till och ta bort tjänster utan att helheten störs.
2. Traditionella CMS
Problemet med de etablerade innehållssystemen (CMS) är att koden man skriver för våra webbsidor kör som en del av CMS:et, för att prata i termer av objektorientering ärver man av CMS:et istället för att använda det. Detta skapar problem:
- Koden man skriver blir hårt knuten till CMS:et, ofta dessutom till en viss version av CMS. Detta gör att uppgraderingar av CMS:et eller ett byte av CMS blir komplicerat. Koden måste dessutom skrivas i samma språk som CMS är skrivet i.
- Det finns ingen separation av data och presentation. CMS:et hanterar både innehållet och renderingen vilket leder till att återanvändning av innehåll för flera kanaler blir svårt.
Till detta kan läggas att den ansedda Technology Radar som publiceras av ThoughtWorks har sedan 2014 avrått från att använda CMS som en bas för utveckling.
3. Huvudlösa CMS
Sedan några år har trenden varit att använda ett så kallat "headless CMS", det vill säga ett CMS som inte ansvarar för hur innehållet presenteras. Inom systemadministration kallas av tradition system som inte har en grafisk miljö "headless", därför används uttrycket även i detta fall.
Ett headless CMS ger redaktörer och administratörer ett gränssnitt för hantera innehåll, användare, behörigheter et cetera precis som traditionella CMS. Innehållet finns därefter tillgängligt i ett API, oftast i JSON-format.
4. Arkitektur med headless CMS
Med ett headless CMS ser arkitekturen annorlunda ut:
När man använder ett headless CMS anropar man det som en separat komponent, istället för att vår kod exekverar i CMS:et. Fördelarna jämfört med det traditionella CMS:et är flera:
- Man kan använda innehållet i flera kanaler.
- Webapplikationen skrivas i vilket språk som helst oberoende av vad CMS är skrivet i.
- Uppgraderingar av CMS:et påverkar inte vår kod direkt.
- Man kan byta ut CMS och applikation separat
Ett headless CMS skapar även möjlighet att använda andra arkitekturer. En sådan som Valtech använt för att till exempel bygga sajten för Internationella e-Sportförbundet är att utnyttja möjligheten att prerendera HTML-sidorna.
Om man skapar webbsidor som ser likadana ut för alla besökare så finns det ingen anledning att rendera dem dynamiskt. Man kan istället generera hela sajten som statiska HTML-filer och låta en webbserver tillhandahålla filerna direkt. Detta skapar en enkel arkitektur som dessutom klarar höga krav på prestanda och säkerhet.
5. Förändringsbart data
Hittills har vi bara arkitekturellt berört organisationen av kod, det vill säga det som hanterar data. För att skapa en flexibel webb måste man även se till datat man lagrar är förändringsbart.
I traditionella CMS lagras allt data i en gemensam datamodell - sidan. Oavsett vad vilket innehåll man hanterar så har man bara har en modell av datat, vilket innebär vissa problem:
- Datat måste ordnas manuellt, till exempel med hjälp av sidträd.
- Förändring och migrering av datat kräver manuell copy-paste.
- Svårigheter att anpassa innehåll för olika plattformar, som diskuterat ovan.
- Hanteringen av översättning av innehåll försvåras.
