Rasmus tænker på CMS
Adm. direktør og partner

Rasmus Luckow-Nielsen

rasmus@reload.dk

30224545

Læs mere om Rasmus

Hvilket type CMS skal jeg vælge?

Når du står og skal havde udviklet en ny it-løsning, har du ofte brug for at kunne administrere forskellige typer af indhold og dernæst præsentere dem på en eller flere platforme. Et content management system (CMS), er særligt egnet til administration af indhold, men dit valg af CMS har stor indvirkning på, hvordan resten af din infrastruktur kan skrues sammen. Der findes mange snitflader, som man kan anskue CMS systemer ud fra. 

Der findes et hav af forskellige CMS’er, og det kan være svært at vælge, hvad der er det rette for jeres organisation. Alle CMS’er vil kunne håndtere de basale krav til håndtering af indhold, men de har en række forskellige styrker og svagheder. I Reload har vi et par favoritter, men lad os starte med at introducere de forskellige kategorier af CMS.

 

CMS

Der er tre grundlæggende modeller, når vi taler CMS - monolitisk, headless og decoupled CMS.

Vi dykker mere ned i det, men helt kort, så er et monolitisk CMS et system, der er lavet til at fungere “stand-alone”. Det er altså en fuld pakke, som står for alt, hvad du har brug for, lige fra indholdsoprettelse til præsentation. 

Et headless system er et system, der kun håndterer indholdet. Dvs. datamodellen og muligheden for at man som redaktør kan oprette indhold. Men det bekymrer sig ikke om præsentationen - meningen er, at andre systemer skal hente data og præsentere det på en meningsfuld måde.

Et decoupled (eller afkoblet) CMS er i virkeligheden bare kombinationen af et headless CMS og en separat frontend der præsenterer indholdet (typisk til web).   

Monolitisk CMS (traditionel CMS)

De traditionelle CMS’er er alle monolitiske i deres tilgang. Det betyder, at du grundlæggende får én samlet pakkeløsning, som indeholder alle de dele og funktionaliteter, du har brug for. Det har den fordel, at du får det hele med på en gang, og du kan sammenligne det lidt med en schweizerkniv. Det kan rigtig meget. Til gengæld er indhold og præsentation ofte ret tæt koblet. Det gør mange ting nemmere at arbejde med og forstå - men kan give problemer, hvis man ønsker at præsentere det samme indhold i mange forskellige digitale kanaler, lige fra en hjemmeside til en app og måske til 3. parts systemer.

Eksempler på velkendte og veletablerede monolitiske CMS’er er: Drupal, Umbraco, Wordpress, SiteCore, Optimizely, Typo3

Alle disse systemer har dog fulgt med tiden og kan også eksponere data afkoblet fra præsentationen og har mulighed for at integrere med mange andre systemer. Men den grundlæggende opbygning er stadig gearet til, at de skal kunne fungere som et “stand-alone” produkt.

I Reload er vi eksperter i Drupal, og vi er stadig rigtig glade for det, fordi det faktisk kan fungere som alle tre typer af CMS; monolitisk, decoupled og headless. Vi har brugt det på alle disse måder. 

Fordele ved monolitisk CMS

  • Du får den fulde pakke
  • De er glimrende til indholdstunge websites, som de oprindeligt blev lavet til
  • Der er store modne communities, der hører til, så det er nemt at finde hjælp
  • Der er mange leverandører til dem
  • De er modne ift. etablerede sikkerhedsopdateringer og release cycles
  • Der er et stort udvalg af plugins og integrationer
  • Der er mange “nemme” muligheder for hosting
     

Ulemper ved monolitisk CMS

  • De er ofte nogle store og “tunge” systemer med meget bagage
  • Programmeringssproget er ofte af ældre dato, fx PHP og .NET, hvor mange udviklere i dag i højere grad orienterer sig mod Javascript
  • De er bygget til et paradigme, hvor alt er hosted på én server og en klassisk request/response model
  • De bliver oftere mål for angreb, og hvis du ikke holder dit system opdateret, så må du forvente, det bliver hacket
  • End-of-life påvirker hele systemet og ikke kun en enkelt service. Dvs. skal du udskifte en del, kan du blive nødt til at udskifte det hele
  • Begrænset frihed ift. frontend frameworks, API lag mv.

Grundlæggende gør et samlet system nogle ting lettere, men andre ting sværere.

Headless CMS

Et headless CMS er grundlæggende et “content repository” - altså et rendyrket redaktionelt interface, hvor du bare skal bekymre dig om at oprette indhold og deres indbyrdes relationer. 

Det er altså et meget rent interface, der grundlæggende står for selve datamodellen og dens indholdsobjekter (fx hvilke felter skal der være på en artikel, event, en video osv), og så selvfølgelig muligheden for at tilføje indholdet.

Du kan altså se det som en slags redaktør-skræddersyet indgang til en indholdsdatabase. Man kan også lægge autentificering og brugerhåndtering i denne ende af systemet.  

Headless CMS konceptet lægger sig op af microservices arkitektur tankegangen, hvor de forskellige separate services fungerer ‘uafhængige’ af hinanden.

Det betyder også, at der skal andre systemer til at hive data ud igen og vise det. Det kunne være på et eller flere websites (via en frontend, fx lavet i React), i en app eller i et helt tredje system. 

Vi har fx lavet et headless cms til DAC, som vi kalder deres content hub. Den føder så indhold til både deres app og website. 

Eksempler på headless CMS'er er: Contentful, Strapi, Prismic, Ghost og mange andre. Vi har også brugt Drupal som et headless CMS. 

Fordele ved headless CMS

  • Indhold og præsentation er helt afkoblet
  • Der er fokus på oprettelse, administration og eksponering af indhold
  • API er nemt at arbejde med
  • Der er UI brugergrænseflade til redaktøren 
  • De er agnostiske ift. hosting, frontend frameworks og programmeringsprog
  • De er uafhængige af drift og deployment
  • De er letvægtssystemer der er nemme at komme igang med
  • De stiller ikke særlige krav til udviklere ift. forhåndskendskab til systemer
     

Ulemper ved et headless CMS

  • Indhold og præsentation er helt afkoblet - det kan være svært at arbejde med
  • Mange løsninger fungerer som SaaS produkter, og derved er det begrænset, hvad du kan gøre med dem. Du har ikke altid fuld frihed til at modificere dem til dine behov
  • Priserne kan hurtigt blive dyre - idet du ofte betaler for trafik eller mængde af indhold, når det er SaaS produkter, du bruger
  • Du får ikke foræret de mange basale ting som oftest kommer med i pakken på monolitiske CMS’er - du skal i mange tilfælde opfinde den dybe tallerken igen
  • Du har som udgangspunkt ikke mulighed for at previewe, hvordan dit indhold kommer til at se ud hos en slutbruger

Decoupled CMS

En decoupled CMS er på flere måder en kombination af en traditionel og headless CMS løsning. Det vil altså sige, at CMS’et udstiller en API, hvor du kan konsumere indhold og samtidig giver mulighed for at kunne formatere indhold mod præsentationslaget.

Det er altså et headless CMS i kombination med et præsentationslag, typisk en webfrontend. Denne opdeling giver en række fordele, fx at teams i højere grad kan arbejde parallelt og med forskellige kompetencer. Det giver også særligt mening at lave et decoupled CMS, hvis præsentationen ikke skal være et traditionelt website. Fx hvis der er behov for at vise data på en helt anden måde, løbende hente dele af data ind eller opdatere det realtime. Eller hvis interfacet grundlæggende bryder med gængse paradigmer, fx kunne det være et spil. Så vil et monolitisk CMS ofte komme til kort, idet det ofte forudsætter en række forhold omkring både indhold og præsentation. 

Så et decoupled CMS giver dig stor frihed til at implementere en frontend / præsentationslag, lige som du ønsker - og i den teknologi du foretrækker eller har størst ekspertise i. Til gengæld skal du så også sørge for det hele selv, hvilket ofte gør det til en dyr vej at gå. 

Decoupled CMS er altså mere end tilgang end et færdigt system, du kan downloade og bruge. Det består altså af en headless backend samt et præsentationslag: Frontenden. 

Frontenden bliver en uundværlig del af det samlede system, og vil ofte være bygget på nogle dedikerede frontend frameworks (fx baseret på ReactJS eller VueJS) eller på frontend template systemer.  

Vi har eksempelvis bygget lokalbolig.dk som et decoupled CMS - her fungerer Drupal som et headless CMS (der forøvrigt samler og eksponerer data fra mange andre kilder) og via et GraphQL API føder det en React baseret frontend. 

Hvad bruger vi i Reload?

I Reload sværger vi til Drupal og Strapi. Drupal er fleksibelt nok til at kunne blive brugt i de fleste konstellationer. Det er i høj grad et hybrid CMS. Men det er også relativt tungt at arbejde med og har en stejl indlæringskurve. 

Til løsninger som er lidt simplere, eller som skal kunne fungere som headless CMS, der peger vi på Strapi, som er et glimrende javascript baseret open source headless CMS, som også kan selv-hostes.  
 

Vil du vide mere?

Så send et digitalt brev til Rasmus Luckow-Nielsen, administrerende direktør i Reload, hvis du vide mere.
 

rasmus@reload.dk  

Kompetencer