Cloud Nine förklarar headless: Är headless rätt för min webbplats?

I den här bloggserien diskuterar jag begreppet headless och besvarar några frågor som ofta ställs till mig i min roll som utvecklare. Vi har tidigare definierat och belyst några av fördelarna med headless, och i det här inlägget ska vi prata lite mer om varför man vill ha en headless-webbplats och några saker man kan fundera på om man vill gå den vägen.

Ja, headless är fortfarande aktuellt

I webbsammanhang har headless hängt med som en tydlig trend ett bra tag nu, och det har inte visat några tecken på att avta. Hos oss på Cloud Nine har det oftast varit vi som försökt förklara vad det är och varför det är bra, men på senare tid har det också börjat dyka upp som krav från kundsidan redan tidigt i diskussioner. Det visar på att det finns en bredare kunskap kring headless och vad det kan tillföra, och det i sin tur innebär att den här trenden nog bara kommer fortsätta att växa sig starkare framöver.

Min uppfattning är att det framför allt finns några saker som gör att headless väcker intresse utanför utvecklarkretsar, kanske främst flexibilitet och utbytbarhet. Helt enkelt att man ser ett värde i att kunna göra förändringar. Både i att små förändringar kan göras snabbare tack vare ett lösare sammankopplat system, men också att man teoretiskt sett kan byta ut ganska stora byggstenar i systemet utan att behöva göra så stora omtag i övrigt. Man ser det som ett mer framtidssäkert sätt att arbeta på, med mindre risk att måla in sig i ett hörn.

En annan faktor som inte ska underskattas är att många moderna webbplatser erbjuder en väldigt trevlig upplevelse genom att använda sig av ett av de stora Javascript-ramverken, med React i täten. De fördelar man får i upplevd hastighet, sömlös navigation och större frihet när man utformar interaktioner på den typen av webbplatser tilltalar många. För att åstadkomma detta på ett bra sätt för en större webbplats, så är headless nog att betrakta som ett krav.

Avgörande faktorer för att välja headless

Så säg då att man tycker att allt det ovanstående låter bra. Det är klart att man vill ha flexibilitet, snabbare förändringar och en hipp React-site. Men om det är vad man vill ha ut av sin site, vad behöver man då uppfylla för att det ska gå att genomföra? I princip krävs ingenting speciellt, men man bör komma ihåg att det är ett lite annat tänk än den mer traditionella webbplatsen. Det kan ha inverkningar på ett antal saker, där det är bra att redan från början ha lite koll på bland annat följande:

Har utvecklingsteamet erfarenhet av headless? Inget absolut krav förstås, men det kan göra att man undviker en del fallgropar. Det är ganska lätt att "råka" bygga sin headless-lösning efter exakt samma tankesätt som en traditionell webbplats, varpå man tappar en del av fördelarna kring flexibilitet.

Är de som ska jobba med innehållet på webbplatsen med på tåget? Ofta kan det vara en lite annorlunda uppgift att jobba med innehåll när det inte är kopplat till en specifik presentation, till exempel kan det upplevas lite mindre fritt, eftersom allt utom den mest grundläggande utformningen generellt styrs av kod snarare än av redaktörer (vilket leder till en konsekvent presentation av allt innehåll).

Har man valt en (eller flera) plattformar som lämpar sig för headless? De flesta större CMS och e-handelsplattformar har idag någon form av stöd för headless, men det är fortfarande värt att ha i åtanke. Det behöver inte vara en "deal-breaker", men om ens plattform inte är redo för det eller inte har tillräckligt bra stöd bör man vara medveten om att det kan kräva extra utveckling, alternativt att man i värsta fall kanske ska tänka om sitt val av plattform. Man bör också komma ihåg att det kan finnas saker som upplevs som inbyggda i en plattform, men som inte automatiskt följer med när man bygger en frikopplad applikation. Det senare gäller framförallt plattformar som inte är byggda för headless från grunden.

Sammanfattningsvis kan man nog helt enkelt säga att headless medför ett lite annat tänk, både i utvecklingsarbetet och för de som ska arbeta med den färdiga produkten. Dock skulle jag säga att de allra mesta, kanske med undantag för en uppstartsfas, blir mer rättframt när man väl är igång, tack vare den tydliga ansvarsfördelningen.

I nästa inlägg kommer jag kika närmare på “mikrotjänstarkitektur”, som ofta nämns tillsammans med headless, samt nämna några korta tankar kring framtiden inom dessa två områden.

/Ronnie Hillgren, Systemutvecklare