Traditionell vs Headless arkitektur på sajten - vad ska man välja?

Om du står för dörren att se över din digitala närvaro i någon form så är det inte otänkbart att du kommer stå inför ett vägval. Det blir helt plötsligt viktigt att du förstår skillnaden mellan en traditionell och en headless arkitektur.

 

Vad är deras olika för- och nackdelar och vilken av dessa passar dig och ditt team av redaktörer, utvecklare, designers och/eller marknadsförare bäst? Om rätt val tas, är chansen att du kan skapa dig en verktygslåda som underlättar ert arbete avsevärt.

 

Webbarkitektur

En makrotrend inom vår digitala värld är behovet av att via multipla kanaler kunna engagera kunder med personaliserat innehåll. Dessa kanaler kan vara hemsidor, appar, sociala medier, intranät, Internet of Things devices, smart watches, emails etc. och gäller vid alla olika stadier i en kundresa.

 

Denna trend har gett plats åt nya verktyg som utmärker sig på att kunna leverera innehåll. Generellt så myntas dessa verktyg tillhöra “The headless web”. Headless verktyg ger en rörlighet och flexibilitet som många företag söker efter. Genom sin approach är det nya verktygen utmanare till de traditionella innehållsplattformar som WordPress och Episerver.


I denna artikeln ska vi reda ut vad headless och traditonella arkitekturer är, deras olika för- och nackdelar och vad de passar för. Om ett begrepp känns obekant har vi lämnat en liten ordlista i slutet artikeln.

 

Traditionella arkitekturer

I ett klassiskt CMS skapas, hanteras och lagras innehålls tillsammans med bilder, filer o.s.v. i backoffice (också ibland kallat för admindelen). I backend skapas också sajtens huvudsakliga struktur samt eventuella grafiska anpassningar. CMS:et som hanterar informationen är också bundet till samma system som levererar och presenterar innehållet  (frontend) till besökaren. Vi säger att backend och frontend är tätt sammanknutet, de består av samma kodbas, samspelar mellan sig och utgör sajten som helhet.


Med andra ord arbetar redaktörer i samma system som besökarna kommer till. Umbraco som vi ofta arbetar med är ett exempel på ett sådant system, WordPress och Episerver är andra sådana exempel.


Till traditionella plattformar tillkommer oftast också ett mer eller mindre omfattande ekosystem av plugins. Ska du integrera formulär på sajten finns det antagligen redan ett plugin som adderar denna funktionaliteten till din sajt. Utöver det har utvecklare möjligheten att nyttja inbyggd funktionalitet för att på ett lätt sätt hantera den lagrade informationen, exempelvis funktioner för att kunna söka på innehåll.

 

 

En annan fördel till dessa klassiska plattformar är att de är kostnadseffektiva om deras inbyggda funktionalitet ligger i linje med vad du efterfrågar. Om du däremot har flera andra system som ska integreras till ett CMS kan det däremot bli dyrt och svårarbetat, beroende utsträckningen det behöver göras anpassningar.

 

Dessa klassiska arkitekturer är skapade utifrån ett specifikt syfte. Om du till exempelvis tittar på en informationssajt med denna typ av arkitektur är den inte nödvändigtvis anpassad för att hantera skyddat innehåll. Med detta menar jag sektioner såsom Mina sidor, forum, recensioner, privat/företag och så vidare.

 

Medan det alltid är möjligt att utveckla dessa typer av funktionaliteter så kan de bli röriga lösningar som blir dyra att förvalta. En utvecklare har också utmaningen att skapa en effektiv databas så att innehåll kan hämtas snabbt och resultera i låg laddningstid för besökaren. En rörig eller komplicerad lösning kan resultera i sämre laddningstider vilket kan vara kostsamt att åtgärda. Ett av de vanliga skälen till att företag väljer att göra om sin sajt är just att den nuvarande är för långsam.

 

Om du också vill ta i beaktning dina redaktörers kompetens i olika plattformar kan det krävas mer eller mindre support samt utbildning. I dessa CMS tenderar det dessutom att finnas en viss mängd kontroll hos redaktörer att kunna styra hur innehållet ska se ut, vilket kan vara ett plus eller minus beroende på hur redaktörens kompetens.

 

Headless Arkitektur

Headless liknar traditionell arkitektur i de avseenden att båda dessa hanterar innehåll, lagrar information i en databas och levererar det innehållet utåt på ett sätt.  



“Headless” — an architectural pattern for software systems, specifically where the software component(s) responsible for executing commercial transactions do not provide a user interface (known as a head)



Ordet Headless syftar på att CMSet levererar information till ett annat system som presenterar informationen för besökaren. Ett CMS som Contentful är exempel på en tjänst som är headless. Med denna typen av arkitektur skapar och hanterar dina redaktörer innehållet i en molntjänst, d.v.s. på en separat sajt. Innehållet lagras sedan och inväntas på att bli hämtas via ett API.



Naturligtvis förblir “Headless” arkitekturen inte utan ett system som ska presentera innehållet med antagandet att du faktiskt vill publicera innehållet du skapar. Valet av det system som ansvarar för att visa innehållet är däremot inte bundet till valet av CMS. Istället är headless arkitekturen agnostisk. Här finner vi flexibiliteten som tidigare nämndes. Som utvecklare finns det ett mycket stort utbud av ramverk att välja mellan. Du kanske har hört talas om React, Vue eller Angular som alla kan skapa oerhört skräddarsydd upplevelse. Fördelen är att olika ramverk och deras ekosystem kan passa vissa ändamål mer eller mindre, men gemensamt är att de utmärker sig med sin prestanda och enorma bibliotek av mikro-funktioner som kan utnyttjas av utvecklaren.

 

 

 

 

När du arbetar med ett headless CMS börjar du med att strukturera upp innehållet. Du avgör vad för typ av innehåll som ska finnas, vilka fält redaktören ska kunna fylla i etcetera. I grund och botten är ett headless CMS enbart rå data, den säger väldigt lite om en inget om hur innehållet ska presenteras. Fördelen med det är att du också kan nyttja innehållet till inte bara en offentlig sajt utan en intern, en business intelligens tjänst eller också för appar, IoT plattformar med mera.



The Headless Web kommer förvisso med en hel del bra förtjänster men nackdelen med denna typen av arkitektur är att om du ska ha liknande funktionalitet som du får “out of the box” med ett traditionellt CMS är att det kan bli i jämförelse kostsamt. Den initiala utvecklingskostnaden är oftast högre med headless arkitekturer men på sikt kan underhåll och vidareutveckling bli billigare samt öppna dörrar för nya funktioner och integrationer som kanske inte fanns på kartan förut.



En headless lösning är inte i handen i handsken för alla scenarion. Däremot om du utnyttjar flera olika tjänster och behöver integrera dem till hemsidan är det enklare att göra det med denna typen av arkitektur. Som utvecklare kan vi använda standardiserade utvecklingsramverk och utnyttja flera olika API:er, varav ett av dem kan vara ett headless CMS.

 

 

 

Det ena eller det andra ..

Det finns också en del traditionella CMS som har på senaste utvecklat tillhörande API:er som kommer med vid installation eller lätt kan göras tillgänglig för att kunna utnyttjas i en headless arkitektur. Det du ska vara medveten om är att viss funktionalitet kanske inte går att levereras via API:et. En stor del av de tidigare plugins som fanns tillgänglig kanske inte kan utnyttjas.


Å andra sidan om du eller dina redaktörer gärna arbetar inom samma CMS som ni är kompetenta inom kan vara värt att titta på en mix av dem två.

 

Sammanfattningsvis .. 

Varje projekt har sina egna förutsättningar och det går inte att ge en allmän övergripande rekommendation. I grova drag vill vi rekommendera att för en enklare och till mestadels informativ webbplats, är en traditionell arkitektur ofta mer kostnadseffektiv. Ifall du har flera olika utomstående tjänster eller integrationer mot externa plattformar kan en headless arkitektur vara vägen att gå. Headless passar perfekt om du har flera olika tjänster som ska integreras.



Det ena alternativet ersätter inte det andra. Headless är inte här för att ersätta traditionella arkitekturer men vi har möjligheten att kunna välja en större bred av andra lösningar utifrån olika behov.

 

På Camelonta skapar vi en god bedömning av er situation och er framtid för att göra rätt vägval. Vi vill också att ni förstår varför vi väljer ett vägval och de vinster eller begränsningar som kan innefattas.



Är du intresserad av att bolla om dessa olika approacher och kanske just vad som skulle passa dig, är du varmt välkommen att höra av dig!

 

Kontakta oss!

Ordlista

 

1. CMS - (Content Management System) En plattform för att hantera innehåll. Kan vara ett sådant som installeras på en server och har likväl ett presentationslager eller vara en molntjänst som endast innehåller information.

 

2. API - (Application Program Interface) ett gränssnitt ofta för utvecklare att kunna skapa egna tjänster baserat på den datan som görs tillgänglig. I många fall är det inte begränsat till att bara hämta data utan också addera eller ändra.

 

3. Ramverk - En samling av funktionalitet för utvecklare att lösa de utmaningar vi arbetar med dagligen. Metaforiskt går det se ett ramverk som tapas. Du kan kombinera flera olika tallrikar för att skapa din middag, likväl om du inte gillade en kan du lätt byta ut den utan att behöva byta samtliga rätter.

 

4. Head - (från ordet “headless”) - Det system eller ramverk som ansvarar för layouten och för att presentera innehållet.

http://camelonta.se//media/1841/blogginla-gg-camelonta.png