Hvad er et Headless CMS?

Teknologi

8. mar.

Mathias giver en introduktion til Headless CMS på vores lightboard

Skrevet af

Mathias Piletti
Udvikler

En hovedløs fremtid?

Udvalget af CMS systemer, som er “headless”, er over de seneste fem år vokset betragteligt. Det er der mange årsager til, men det kan til en vis grad tilskrives nye måder, frontend frameworks anvendes og nye brugsbehov i forhold til, hvordan ens data skal interagere med et flertal af services. Dette stiller nye krav til, hvordan indhold administreres (“body”), og hvordan indhold præsenteres (“head”).

Når man omtaler en CMS løsning som “head”-less, refereres der til, at CMS løsningen udelukkende har holdninger til “body” delen. Dette betyder, at CMS’et udstiller en grænseflade, hvor du kan oprette indholdstyper, indsætte indhold, fremsøge, filtrere og sortere indholdet, men det er fuldstændig agnostisk i forhold til, hvor og hvordan du ønsker at vise indholdet.

*Eksempel hvor indholdet lever i CMS’et, men præsenteres på en hjemmeside*

Da administration og præsentation af indhold er adskilt, har det den positive følgeeffekt, at man har friheden til at implementere de omkringliggende services præcis efter eget ønske og brugsbehov.

For eksempel kan man gnidningsfrit indsætte en anden service foran CMS’et, hvis man pludselig finder ud af, at man har brug for at forberede svartiderne. Det kan også være, at man af sikkerhedsmæssige hensyn ikke ønsker, at websitet skal kunne kommunikere med CMS’et direkte.

Måske skal de besøgende kun kunne tilgå noget bestemt indhold efter, at de er autentificerede, eller måske skal indholdet beriges og formateres, før det sendes videre til den næste service. I takt med at ens arkitektur vokser, er der ofte også en interesse i, at flere forskellige services kan konsumere det samme indhold, men vise det på forskellige måder (såsom en app, hjemmeside og andre interne systemer).

Da CMS’et er blot er en byggeklods på lige niveau med de andre services i din arkitektur, er denne slags udvidelser trivielle til sammenligning med klassiske monolitiske applikationer. Med andre ord opnås denne fleksibilitet ret smertefrit, fordi de forskellige services er isolerede og på mange måder uafhængige af de omkringliggende systemer. Dette er i trit med med microservice tankegangen.

*Eksempel på hvor de enkelte services er adskilte og bliver afviklet uafhængigt af hinanden.*

Hvad skal jeg overveje, når jeg skal vælge et nyt headless CMS?

I Reload har vi fulgt denne udvikling over de senere år og eksperimenteret med, hvilke nye muligheder og overvejelser som er vigtige at inddrage i ens betragtning, når man vurderer, hvilket headless CMS man ønsker at anvende til sin nye it-platform. Vi har undersøgt markedet for eksisterende headless CMS løsninger og vurderet dem på baggrund af en række forskellige faktorer. Vi anbefaler Strapi som headless CMS.

Med udgangspunkt i en række kriterier vi beskriver nedenfor, har vi afprøvet mange forskellige headless CMS løsninger. Det dækker både over løsninger som open-source vs closed-source, managed vs self-hosted og gratis vs proprietære. Fælles for mange af systemerne er, at de på nogle kriterier klarer sig rigtig godt, mens der er andre kriterier, hvor de halter bagud. Hvilket CMS der er egnet til din løsning, afhænger derfor af dine brugsbehov.

For nogle kunder vil det være helt centralt, at man kan styre brugerrettighederne på et meget granulært niveau, da der rigtig mange forskellige profiler involveret, som skal havde forskellige typer af rettigheder.

For andre er det måske mere centralt, at CMS systemet er meget fleksibelt ift. at opbygge en kompliceret datamodel, og hvor tilhørende medieindhold kan serveres lynhurtigt for alle ens besøgende.

Vi har forsøgt at evaluere på ret mange forskellige headless CMS systemer (bla. Strapi, ButterCMS, Contentful, DatoCMS), og vores favorit baseret på alle førnævnte kriterier er Strapi CMS. Det skyldes, at Strapi klarer sig godt all-around i størstedelen af kategorierne og fremragende i nogle enkelte kategorier såsom administration af indhold, muligheder for videreudvikling og open-source med en yderst fair pris-model.

Strapi er det mest populære open source CMS udviklet i programmeringssproget JavaScript.

“Kort” om Strapi

Strapi kan fungere som en samlende platform til håndtering af alle CMS-relaterede behov, altså redaktørgrænsefladen og strukturering af indhold til digitale kanaler. Strapi understøtter komponentbaseret opbygning af indhold, hvilket giver redaktører stærke værktøjer til opbygning af engagerende artikler og avancerede landing pages på en let og overskuelig måde. Derudover kan Strapi håndtere en række af de funktionaliteter, de fleste ønsker sig af et fremtidigt CMS, eksempelvis automatisk nedskalering af billeder og håndtering af metatags. Det gør det både nemmere og hurtigere at arbejde med for redaktøren, men har også den fordel, at det øger hastigheden på sitet og dermed også sidens SEO ranking.

Strapi er som beskrevet et headless CMS, hvilket betyder, at det er bygget til at opbevare indhold der bliver udstillet gennem et standardiseret API frem for gennem websider. Selve webgrænsefladen henter indholdet fra API’et og bliver bygget i en teknologi der giver os de bedste vilkår for at skabe en optimal oplevelse for slutbrugeren. Her tænker vi særligt på at skabe dynamiske oplevelser på et site, hvor dele af sidens indhold ændrer sig baseret på brugerens færden på sitet. I stedet for at hele siden skal genindlæses, så indlæses indhold dynamisk. Samtidig giver det også Strapi mulighed for at fokusere på at skabe en optimal redaktørgrænseflade og lade andre systemer i arkitekturen stå for selve præsentationen.

Strapi er fleksibelt og modulært.
Det vil sige, at det i fremtiden vil være muligt både at tilføje flere indholdstyper og ændre/udvide de eksisterende efterhånden, som forretningen udvikler sig.

Kriterier du skal vurdere, når du skal vælge et (headless) CMS

CMS grænsefladen er det første, du bliver præsenteret for, når du logger ind på dit headless CMS. Det har stor betydning for den samlede brugeroplevelse, at interfacet er hurtigt, indbydende og intuitivt, da systemet ellers er i vejen for den daglige anvendelse.
Et af de mest centrale kriterier der indgår i vores vurdering af et headless CMS er, hvordan man arbejder med indhold og indholdstyper. Dette kommer til udtryk gennem:
Hvilke felttyper systemet stiller rådighed, og hvilke muligheder der er for brugerdefinerede typer
Opbygning af relationer mellem indholdstyperne
En komponentbaseret tilgang der gør enheder genbrugelige
Fremsøgning, filtrering og sortering af indhold baseret på felter
Derudover er der tit knyttet forskellige typer af medier (billeder, video, PDF filer, m.m.) til indholdet. Her er det gavnligt, hvis platformen understøtter muligheden for, at man f.eks. kan formatere billeder gennem beskæringen, roteringen og tilknytning af tekstbeskrivelser - og at billederne bliver konstrueret i forskellige størrelser og billedeformater.
Da et headless CMS ikke har en holdning til, hvordan indhold skal præsenteres, er det helt essentielt, at ens andre services kan konsumere indholdet gennem et API. Denne understøttelse foregår gennem et REST og/eller GraphQL API. Det er vores erfaring, at kvaliteten af det automatisk genererede schema som API’et udstiller, er ret forskelligt og kan have stor indvirkning på, hvilke muligheder man har, når man sender forespørgsler mod CMS'et. Det er derfor vigtigt at vurdere, hvorledes API endpointet bliver konstrueret og hvilke query parameters m.m. der understøttes.
For nogle typer af virksomheder er oprettelse af brugere, rollestyring og granulær kontrol over, hvilke adgange og rettigheder de enkelte kontier skal have en vigtig funktionalitet. Ligeledes vil det for nogle være et behov som skal kunne understøttes programmatisk. Da vi lavede denne sammenligning på tværs af CMS’er, så vi et ret stort udsving i, hvilken styring der var supporteret - alt fra et komplet RBAC med brugerdefinerede roller, til ingen kontrol overhovedet.
Installation og løbende opdateringer er tit et undervurderet kriterie som er helt centralt, når man går fra udvikling til den daglige drift. Det skyldes, at der jævnligt bliver fundet sikkerhedsbrister i ens CMS system, hvor man er nødsaget til at reagere hurtigt imod fremtidige potentielle angreb. Afhængigt af miljøets modenhed, kan anbefalingerne, proceduren og den generelle reaktionstid for de tilhørende vedligeholdere af CMS’et være vidt forskellige.
Fremgangsmåden i forhold til de løbende opdateringer til CMS’et kan også variere ret meget i kompleksitet. Det har stor indvirkning på den månedlige økonomiske drift der er forbundet med projektet. Det er derfor en god ide at være opmærksom på disse skjulte omkostninger, når man evaluerer, hvilket CMS man ønsker at anvende.
Slutteligt kan opsætning og migration af indhold mellem platformene på nogle projekter også være aktuelt, men hvordan dette fungerer kan variere betydeligt. Afhængigt af hvilket fællesskab der eksisterer omkring den pågældende CMS løsning, kan brugeraktiviteten variere ret betragteligt. Dette kan tit havde betydning på, hvor hurtigt man kan finde en løsning, da et stor community tit vil medføre, at der allerede er andre som er stødt ind i det samme problem som end selv.
Afhængigt af projektet vil der ofte være behov for at udvide CMS’et med yderligere typer af funktionalitet. Dette kan som regel opnås, hvis der er et livligt økosystem som arbejder på eksisterende pakker, plugins og adapters der passer til CMS’et. Ligeledes har vi ofte behov for at tilføje udvidelser til dele af CMS’et med specialbygget funktionalitet.
Det kan f.eks. være, man har brug for at redigere landingssiden, således at der bliver præsenteret noget information der er aktuelt for ens redaktører. Det kan også være, man ønsker at reagere på bestemte typer af “events”, som kan blive triggered gennem såkaldte “lifecycle hooks”.
Afhængigt af hvorvidt CMS løsningen er open-source, og hvordan kodebasen er skruet sammen, kan det havde vidt forskellig indvirkning på, hvilken frihed man har til at berige CMS systemet med yderligere funktioner.
Understøttelse af flere sprog, tal, datoformater m.m. kan være behov, som man har fra starten - men hvis behovene pludselig opstår, og systemet ikke understøtter dem, kan det hurtigt blive problematisk ift. at kunne rykke hurtigt.
For at opnå den bedst mulige DX oplevelse er det altid en stor fordel, hvis dokumentationen og best practice anbefalingerne er formuleret på en gennemarbejdet, letlæselig måde. Hvis der ikke er en beskrivelse og guides på de forskellige underliggende delsystemer, kan det godt tyde på, at CMS projektet ikke er nået til den del af modningsfasen endnu, og vi vil derfor være påpasselige med at anvende systemet i produktion til større projekter. Derudover kan beskrivelserne på diverse commits og release tags i repositoriumet tit være en indikator for kvaliteten og den tilhørende struktur i kodebasen.
Landskabet for de eksisterende hostingløsninger, prismodeller og licenser kan variere betragteligt, så det er svært at definere nogle generelle anbefalinger uden at have kendskab til forretningen.
Det er dog værd at bemærke, at at open-source løsninger som regel giver udviklerne mere frihed og indsigt i, hvordan CMS’et er skruet sammen, og dermed flere muligheder ift. at udvide systemet til de brugsbehov, ens kunder har. Til gengæld er det ofte på bekostning af, at man selv tit er nødsaget til at hoste løsningen, hvilket kan medføre nogle af de udfordringer der er beskrevet i punkt 5. Self-hosted er typisk billigere, så længe der ikke er problemer med migration mellem versionerne, men typisk dyrere i udviklertimer når løsninger skal opdateres til en ny major version.
Derudover kan nogle typer af licens indeholde restriktioner som kan have indvirkning på, hvilke muligheder man har for at anvende CMS’et i forretningsøjemed.
Sproget løsningen er udviklet i vil typisk kun være rettet mod de udviklere som skal drive og videreudvikler løsningen. Vores anbefaling er derfor først og fremmest at sikre, at de interne tilknyttede udviklere har erfaring med sproget, og sekundært at det er et populært sprog som flere kan bidrage med.
Derudover kan et programmeringssprog med type definitioner tit være behjælpeligt, da det har en kommunikativ effekt mellem de forskellige udviklere. Et tilhørende CLI værktøj til CMS systemet kan også være gavnligt, da det kan hjælpe med at automatisere flere af de kommandoer man ellers vil være nødsaget til manuelt at skulle klikke sig igennem.
I vores løsninger tager vi sikkerhed alvorligt, og i vores øjne er det derfor relevant, hvordan de tilknyttede maintainers håndterer sikkerhedshændelser (samt de efterfølgende postmortems) som løbende bliver identificeret. Det er imidlertid værd at understrege, at de mest populære CMS systemer oftest er dem, som er målrettet flest angreb imod, fordi det er de systemer der bliver anvendt af flest.
Elementer såsom release cycles, reaktionstid på oprettede issues, og generel github aktivitet kan dog også være gode indikatorer for, hvilken vækst og modenhed der er i fællesskabet. Og slutteligt kan simple metrikker som github starts og weekly-download også give indsigt i aktiviteten.
Alvoren af hvordan data administreres er via GDPR vokset betragteligt de seneste fire år. Det er derfor centralt at forholde sig til, hvilken type data man opererer med, og hvem der har læseadgang til fortrolig information. Der forventes, at tilgængelighed bliver et opmærksomhedspunkt som også bliver aktuelt fremadrettet, og det er derfor en god ide at sikre sig, at CMS løsningen faciliterer muligheden for at understøtte de krav der eksisterer på området.Item description