Kriterier du skal vurdere, når du skal vælge et (headless) CMS
Brugergrænsefladen
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.
Oprettelse og administration af indhold
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.
API
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.
Brugerstyring
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.
Miljø og fællesskab
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.
Tredjeparts integration
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.
Internationalisering
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.
Dokumentation
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.
Hosting, prismodel og licenser
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.
Programmeringssprog og CLI værktøj
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.
Sikkerhed og modenhed
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.
GDPR og tilgængelighed
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.
