Hvad er Headless CMS?

Kort fortalt betyder ‘headless CMS’, at du kan levere din indhold til flere forskellige applikationer synkront, da dit system altså ikke kun har ét ”hoved”.

CMS står for Content Management System, og er en måde, hvorpå du kan oprette, redigere og publicere din content. Pointen med headless er, at du ikke ønsker et fast defineret hoved, men at du selv kan vælge hoved/hoveder til dit CMS.

Hvad er forskellen på traditionel CMS og headless CMS?

For at komme med en ordentlig forklaring på, hvad et headless CMS er, giver det bedst mening at sammenligne med det traditionelle CMS. Hvis du synes, det er noget forvirrende, så frygt ej. Jeg vil nemlig bruge en tændstikmand som en lille metafor til at forklare forskellen mellem disse to.

Benene er dit redaktørinterface, som er her, hvor du kan oprette, redigere og publicere din content, og det er altså det, der er brug for, for at det hele fungerer og løber rundt. Dernæst har du din database med content, som er din krop og altså hjertet af dine data. Til sidst har du så dit hoved, som er din repræsentation af dine data, altså det, som dine besøgende på applikationen vil se. Dette kan for eksempel være dit website, webshop, digitale tilbudskatalog eller en app.

Pointen her er, at i det traditionelle CMS er hovedet en integreret del af dit CMS, og bliver derfor ofte refereret til som en monolit; altså én samlet enhed. Datastrukturen og understøttelsen af kommunikationsprotokoller er derfor typisk bygget op omkring, at man kun har ét hoved, som ikke kan skilles fra de andre dele.

På den anden side har du vores headless CMS, og her vi bliver lige ved tændstikmandmetaforen. Du har stadigvæk dit redaktørinterface, og din data backend med din content, som kan være dine produkter, blogposts, nyheder og så videre. Det er altså her, du har din content-database. Hertil ligner det således det traditionelle CMS. Dog er en headless CMS-arkitektur bygget op omkring, at det skal fokusere på content, hvilket er til din fordel.

Forskellen er, at dit CMS nu er headless (hovedløs), hvilket betyder, at du simpelthen frakobler hovedet, som ellers normalt er integreret med dit CMS. Med headless vælger du selv hvilken applikation/applikationer, som din content-data skal sendes til, altså dit hoved/hoveder. Dine hoveder kunne for eksempel være et website, et tilbudskatalog og en app. Dette betyder også, at du pludselig ikke låser dit hoved til en bestemt teknologi eller et specifikt programmeringssprog. Dette kan man typisk ikke gøre på samme måde ved det traditionelle CMS, fordi det hele typisk er opbygget i en arkitektur med fokus på, at det skal hænge sammen. Derudover indeholder et traditionelt CMS typisk også en masse andet funktionalitet, som muligvis ikke har noget med content at gøre. For at opsummere så er pointen, at du selv kan vælge hoved/hoveder, når du gør brug af et headless CMS.

Fordele ved headless CMS

Fordelen ved headless er, at du selv kan vælge, hvilke hoveder (website, tilbudskatalog, webshop etc.) du sender din content-data til. Din content leveres altså blot som data ved hjælp af en given API. Dette gør det udviklervenligt, da udvikleren får serveret content-data, og kan derved selv bestemme teknologier, programmeringssprog, og hvordan de vil præsentere data i deres interfaces.

Det gør det ligeledes også nemmere for redaktøren at udgive og redigere content på tværs af applikationer fra ét CMS. Du har her mulighed for at udskifte eller tilføje nye hoveder, uden at det påvirker de øvrige hoveder. Hvis du derimod bruger det traditionelle CMS, skal du typisk udskifte hele CMS og flytte al din content til den nye applikation.

I forlængelse af dette er der en anden fordel, fordi du har mulighed for at bruge den samme content-data på tværs af dine hoveder (applikationer), og kan derved koble flere websites eller apps til samme content. Du kan altså herved spare på dine interne ressourcer, da redaktører ikke skal ind i 10 forskellige systemer for at redigere content.

Ulemper ved headless CMS

Kigger vi på ulemperne, er der selvfølgelig også noget, som du skal tage højde for. Et headless CMS vil sætte nogle større krav til, hvordan du strukturerer din data og arkitektur fra start. Derudover vil det også i de fleste tilfælde kræve en udvikler, når du skal lave nye applikationer. Ved det traditionelle CMS kan du derfor til tider komme længere som almen bruger uden udviklerskills, fordi du kan få lov til selv at opbygge dit hoved (UI) i for eksempel WordPress, hvilket de fleste kender.

Startomkostninger ved at vælge headless kan i nogle tilfælde være større, men du vinder også typisk noget på længere sigt i forhold til skalerbarhed og vedligeholdelse. Hvis du derimod er en stor butikskæde eller blot ved, at du kommer til at udvide dit antal af applikationer, der skal have det samme content, så kan det på den længere bane være langt billigere for dig. Grunden til dette er, at I slipper for at lave flere enkeltstående monoliter, hvor du har brug for mange forskellige udviklere til at vedligeholde hvert CMS. Så der ville det give mere mening med headless, hvor alt content vil være samlet på ét sted. Dog skal du altid huske at rådføre dig, da valget typisk afhænger af, hvilket behov du vil have opfyldt.

Hvorfor er headless CMS kommet på dagsordenen?

Det er det, fordi mængden af teknologier og måder at bygge applikationer stiger helt vildt. Man har altså fundet ud af, at der er et stigende behov for, at der ikke er en redaktør til hver enkelt ting, men derimod kan styre al content fra ét sted.

Du bruger altså konceptet ”separation of concern” ved at ligge ansvaret for content ét sted, hvorfor det kan være en mere langtidsholdbar løsning.

Derudover må det dog også siges, at være blevet lidt af et buzzword. Konceptet om at frakoble serverside fra clientside har været der i længere tid, men nu er der kommet øget fokus på det i forhold til content.

For at runde af…

Jeg håber, at det giver lidt mere mening for dig nu. Hvis du stadig synes, det er en smule komplekst, har jeg samlet de vigtigste pointer nedenfor:

• Pointen med headless er, at du ikke ønsker et fastdefineret hoved, men at du selv kan definere flere hoveder der bruger din content.
• Forskellen mellem det traditionelle CMS og headless CMS er, at arkitekturen i det traditionelle CMS er bygget ud fra, at dit interface er koblet sammen med din backend, hvor du derimod har frakoblet hovederne i headless CMS.
• Fordelen ved headless CMS er, at du kan få sende din content fra et sted ud til flere applikationer.
• Ulempen ved headless er, at du typisk skal bruge udviklere, og have gennemtænkt din arkitektur, hvilket kan øge dine startomkostninger.

Når hvor det er beskrevet hvad et headless CMS er og dets fordele og ulemper, så vil det være normalt at stille spørgsmålet hvordan bruges det så? Læs mere om det her.