Hva er et hodeløst CMS?

Et hodeløst CMS er et innholdsstyringssystem som skiller innholdsstyringen i backend fra frontend, eller presentasjonslaget.

Frontend, eller presentasjonslaget, er alt en bruker ser og samhandler med, tradisjonelt på et nettsted, men i dag på alle enheter med Internett-tilkobling. Dette laget omfatter aspekter ved et nettsted som bilder, tekst, oppsett osv. De tre vanligste frontend-utviklingsspråkene er HTML, CSS og JavaScript.

Backend er utviklerens side av nettstedet, der server-, applikasjons- og databaseinformasjon administreres. Her styres derfor aspekter ved et nettsted som regler, integrasjoner og hvordan sidene er koblet sammen. Vanlige backend-utviklingsspråk er blant annet .NET, SQL og Java.

I en headless-arkitektur er altså hodet, eller frontenden av systemet, avskåret fra kroppen, eller bakenden av systemet.

Med et headless Content Management System kan du drive ulike kundevendte digitale opplevelser, inkludert native mobilapper, smartenheter eller eksisterende webapplikasjoner som ikke er bygget direkte i selve plattformen.

Forskjellen mellom hodeløse og tradisjonelle innholdsstyringssystemer

I motsetning til et tradisjonelt CMS er front- og backend to helt separate systemer i et hodeløst CMS.

Hva er et tradisjonelt CMS?

Et tradisjonelt CMS er også kjent som et "koblet" eller "monolittisk" CMS. Populære CMS-plattformer som bruker en koblet arkitektur, inkluderer WordPress og Acquia.

I et tradisjonelt CMS er head (eller frontend) og body (eller backend) koblet sammen, og sammen håndterer de både innholdet og presentasjonen av innholdet. Tradisjonelle CMS-er leveres ofte med en WYSIWYG-editor (What You See Is What You Get). For å gjøre det tydeligere bruker vi begrepet "koblet" nedenfor når vi refererer til tradisjonelle CMS-er.

Koblet CMS vs. frikoblet CMS vs. headless CMS

Koblet, frikoblet og hodeløs er ulike former for leveringsarkitekturer for innholdsstyring. En leveringsarkitektur er forholdet mellom hvor innholdet administreres og hvor det leveres.

Den vanligste leveringsarkitekturen er en koblet arkitektur, der frontend og backend er bundet sammen. I en koblet arkitektur opprettes, administreres, lagres og leveres innholdet i samme system.

Et CMS som Optimizely CMS kan brukes som en koblet eller en hybrid CMS-løsning. Mange CMS-leverandører tilbyr bare ett av disse oppsettene, og det er lurt å veie alle fordeler og ulemper opp mot hverandre.

Et frikoblet CMS skiller frontend og backend. Innholdet administreres separat fra leveransen. Det utarbeides i backend, og leveres og presenteres i frontend gjennom API-er. Et frikoblet CMS gjør det mulig for innholdsansvarlige, redaktører og designere å jobbe på frontend, mens utviklere jobber på backend.

Til slutt er en headless-arkitektur en ren innholdsdatakilde uten et presentasjonslag. I praksis er headless egentlig bare en annen form for frikoblet arkitektur, men i stedet for at CMS-systemet sender artefakter til frontend, henter frontend innhold fra CMS-systemet.

Det er viktig å merke seg at ikke alle headless CMS-løsninger er like. Noen av dem er rene headless-løsninger, mens andre er en blanding av headless og tradisjonell arkitektur. Et rent headless-system gjør aldri noe med templating og serverer bare rådata til et annet system. Et hybrid headless-system kan derimot operere i en tradisjonell koblet arkitektur, men har også verktøy for å servere innhold headless.

Koblet CMS vs. frikoblet CMS vs. hodeløst CMS i korte trekk

Her er en rask oversikt over hvordan koblede, frikoblede og hodeløse CMS-er skiller seg fra hverandre:

Koblet CMS Frakoblet CMS Hodeløst CMS
Front- og backend er knyttet sammen. Front- og backend er adskilt. En ren datakilde uten presentasjonslag.
Innhold opprettes, administreres, lagres og leveres i samme system. Innholdet administreres separat fra leveransen, slik at redaktørene kan jobbe på frontend og utviklerne på backend. I stedet for at CMS-systemet sender artefakter til frontend, henter frontend innhold fra CMS-systemet.
Én kanal. Omnikanal. Omnikanal.

Slik fungerer headless-arkitektur

En headless-løsning er et CMS som kun bruker backend, og som er bygget med et repositorium som kan nås for eksempel gjennom et RESTful API for visning i flere kanaler. Et API er et sett med regler som gjør det mulig for programmer å snakke med hverandre. RESTful eller REST (Representational State Transfer) er et sett med regler som utviklere følger når de oppretter API-et. API-er gjør det mulig å hente innhold til presentasjonslaget og motta kommandoer fra brukerne til den hodeløse applikasjonen.

Et headless CMS har en database som man kan lese og skrive innhold til, og et administrasjonsgrensesnitt der brukerne administrerer innholdet. En headless-løsning tillater bare oppretting, lesing, oppdatering og sletting av innhold.

I en headless-arkitektur kan utviklere bruke et hvilket som helst frontend-verktøy til å presentere, gjenbruke og levere innhold til alle kanaler. Separasjonen av frontend og backend gjør det enklere å oppdatere de underliggende systemene uavhengig av hverandre, blant andre fordeler som vi kommer tilbake til i et senere avsnitt.

Hvordan hodeløse innholdsstyringssystemer ble til

Innholdsstyring dukket først opp med statiske nettsteder på 1990-tallet, under Web 1.0. Disse nettstedene var enkle HTML-tekstfiler. Innholdsstyring har utviklet seg fra Perl-skript og flate filer til robuste CMS-tilbud og til og med sofistikerte DXP-er.

Utviklingen av det hodeløse CMS-systemet ble drevet frem av mobilrevolusjonen, fremveksten av omnikanalpublisering og JavaScript.

Da mobilteknologi og enheter som klokker og stemmestyrte assistenter kom på banen, trengte brukerne fleksibilitet til å skyve innholdet dit de trengte eller ønsket, noe som var en utfordring for tradisjonelle innholdsstyringssystemer.

Da jQuery ble introdusert i 2007, ble JavaScript i tillegg et rikt programmeringsmiljø, og ideen om å lage en nettside i en nettleser ble en realitet. Utviklere kunne hente rene data fra serveren og sette dem opp i en mal på kundens nettsted.

Teknologien er i stadig utvikling og former CMS-landskapet. Fordi et hodeløst CMS gjør det mulig å integrere med andre teknologier og applikasjoner etter hvert som de dukker opp, er det en svært vanlig leveransearkitektur i dag.

Er headless CMS riktig for meg?

I dag er det ofte utviklere som velger headless fordi de mener at de får mer fleksibilitet med en headless-løsning, og fordi de forstår konsekvensene av API-er, CDN-er og SDK-er. Men er en headless-løsning virkelig riktig for deg?

Til syvende og sist må markedsførere og teknologipersonell avgjøre om en headless-løsning vil hjelpe organisasjonen med å tette hullene i kundeopplevelsen raskere, billigere og bedre enn eksisterende alternativer.

Akkurat som alle andre teknologiske beslutninger har headless-arkitekturer både fordeler og ulemper. Til syvende og sist må du avgjøre hva som er riktig for din virksomhet.

Husk at det finnes andre krav enn headless som du bør ta hensyn til når du skal velge CMS, og at det finnes ulike personas som innholdsredaktører, nettstedsadministratorer, utviklere og markedsførere som du bør aktivere med CMS-et ditt. Å kjøpe innholdsteknologi kan være en forvirrende prosess.

Fordeler og ulemper med et hodeløst CMS

Et headless CMS kan integreres med annen teknologi, hjelpe deg med å nå ut til kundene på nye berøringspunkter og svare på endrede kundeforventninger. Vi har skrevet om noen av fordelene med headless-teknologi her, men her er en rask oppsummering:

  • Integrer med annen teknologi

    Du bruker sannsynligvis dusinvis av teknologier for å drive ulike faser i kundereisen. I stedet for å bruke hundretusener av kroner på å bytte ut disse eldre systemene, implementerer mange bedrifter et headless CMS som kan integreres med nåværende og fremtidig teknologi. En sterk headless-infrastruktur for innhold vil forene innholdet og eliminere siloer.
  • Nå ut til kundene på nye berøringspunkter

    Etter hvert som smartklokker og andre smarthjem-enheter blir stadig mer utbredt og modent, trenger organisasjoner et CMS som kan levere innhold til disse kanalene. Et headless CMS kan integreres i det underliggende rammeverket som brukes av smartenheter, slik at du kan levere de opplevelsene sluttbrukeren forventer.
  • Svar på endrede kundeforventninger

    I et headless CMS skaper tverrfunksjonell frontend-kode kontinuitet i brukeropplevelsen og gjør i teorien organisasjoner raskere i stand til å levere på oppdraget sitt, samtidig som de blir mer lydhøre overfor endrede kundeforventninger.

Team som vurderer å migrere til en ren headless-løsning, oppdager ofte at selv om rene headless-løsninger bidrar til å løse noen problemer, introduserer de også noen nye utfordringer. Hvis du vurderer å gå over til en headless-løsning, må du forstå fordelene og ulempene ved å ta dette valget.

  • Ikke alltid enklere å administrere

    I utgangspunktet kan det virke tiltalende og enkelt å oversette innholdet ditt til rådata som kan brukes av en hvilken som helst plattform.Men headless løser ikke alltid kompleksiteten, ofte flytter den bare rundt på den. Bedrifter finner ofte ut at de trenger mer funksjonalitet enn det som er innebygd i CMS-systemet, og må derfor tilpasse.
  • Ikke alltid raskere eller billigere

    Vurder tiden til verdi og de totale eierkostnadene for ethvert system du vurderer.Hvis du velger et rent headless CMS, må ingeniørteamet ditt ta på seg mer ansvar for å bygge ut ulike modeller og maler. Selv om denne tilnærmingen gir kontroll og tilpasningsmuligheter, kan det ta tid å få et hodeløst system opp og gå, mens ingeniørene samler inn krav, utformer modeller og moduler og bygger dem.
  • Har ikke alltid alt du trenger innebygd

    Rene hodeløse systemer mangler ofte funksjoner som arbeidsflyter eller til og med dra-og-slipp-redigering. Implementeringer mislykkes fordi de ikke har de innebygde funksjonene. Teamene må ofte bygge funksjonaliteten som følger med et tradisjonelt CMS eller et hybrid headless CMS. Innholdsskapere må kanskje vente på teknisk støtte hvis de har mer tilpassede krav til en ny landingsside som ikke støttes av tidligere opprettede moduler eller maler.
  • Ikke alltid funksjonelt for markedsførere eller forretningsbrukere

    Siden headless fjerner presentasjonslaget som følger med applikasjonen, støtter de fleste headless-plattformer ikke ledende brukerverktøy for forretningsbrukere, som redigering i kontekst eller forhåndsvisning av innhold før publisering.

Optimizely CMS er headless, hybrid og koblet, alt-i-ett

Optimizely Content Management System (CMS) har tradisjonelt vært kjent som et koblet CMS. Skillet mellom dette og et hodeløst eller frikoblet CMS er imidlertid mye mindre enn markedet vil ha det til. Optimizely har alltid kunnet tilby en hybrid headless-løsning.

Fordi CMS-et vårt håndterer innhold, og ikke nettsider, er innholdslageret abstrahert fra innholdsleveransen. CMS-et vårt har en kontinuerlig lanseringsstrategi og en API-først-arkitektur som har holdt tritt med utviklernes behov, uten at vi har måttet ty til fullstendig omskriving og nye produkter for å støtte dagens mangfoldige publikum.

Headless CMS blir ofte fremstilt som det motsatte av et tradisjonelt web-CMS. Vårt CMS avviser denne ideen. Faktisk er headless et tillegg til det Optimizely-plattformen normalt gjør. Den ene disiplinen er ganske enkelt en forlengelse av den andre. Og her er grunnen til at dette er viktig: fordi det er en naturlig overlapping mellom de to disiplinene. Optimizely trengte ikke å bygge et nytt CMS fra bunnen av - kjerneproduktet web-CMS er en naturlig og fleksibel base for et alternativt leveringsparadigme.

Hvis du vil se et eksempel på Optimizelys headless-løsning i praksis, kan du ta en titt på The Student Hotels historie om digital transformasjon. Ved hjelp av et headless-rammeverk har Studenthotellet levert et lynraskt og effektivt nettsted.

Optimizely CMS er hodeløst når du trenger det, og et fullt utstyrt, koblet CMS når du ikke trenger det.