Hybrid eller headless CMS?

Markedet for såkalte headless CMS løsninger har vokst mye de siste årene. Det har gitt utallige "evangelister" og "teknorådgivere" mye å snakke om. Vi er vitne til et nytt "buzzword" og et slags paradigmeskifte - der "alle" vil inn, uavhengig av deres kunnskap eller ferdigheter.

Det første spørsmålet å stille seg er om løsningen eller teknologien passer inn i den eksisterende arkitekturen i din organisasjonen. Videre hva er de virkelige behovene og kravene? Kanskje du ikke bør konkludere for tidlig om headless eller ikke, men i stedet vurdere en løsning som kalles "hybrid CMS."

Basert på dine krav kan du trekke tre konklusjoner: 

• Hvis prosjektet ditt bare krever et grunnleggende nettsted, er sannsynligvis et tradisjonelt CMS alt du trenger. 
• Hvis prosjektet ditt er fokusert på en app eller IoT, med begrensede redaksjonelle krav - kan et cloud native headless CMS oppfylle dine behov. 
• Hvis prosjektet trenger rich tekst innhold, URL-håndtering, omfattende redaksjonelle krav, spesielle hosting behov og gjenbruk på tvers av forskjellige kanaler, kan et hybrid CMS være løsningen du leter etter. 

I et tradisjonelt CMS er det en tett sammenheng mellom funksjoner for redaktørene og funksjoner for utviklerne - mellom innholdslaget og presentasjonslaget. Redaktøren har  tilgang til full forhåndsvisning, redigering av destinasjonssider, URL-håndtering, detaljert tilgangskontroll og mediearkiv. Mens utviklerne kan kode, teste og distribuere både redaksjonell og sluttbrukerfunksjonalitet samlet. Dette er mulig ved en tett kobling mellom leveringslaget og CMS. 

En ulempe med tett kobling i tradisjonelle innholdsstyringssystemer er distribusjonen til flere kanaler. En standard nettleser, en mobilapp, en bærbar, digital skilting og en Internet of Things (IoT) -enhet kan ikke lese og presentere innholdet når presentasjonslaget er laget eksklusivt for nettet. Det er der hodeløs CMS kommer inn.

Mobilapper, sosiale medier, smarte klokker, digital skilting, selvbetjeningsmaskiner, roboter og utallige IoT-enheter endrer måten vi bruker digitalt innhold på. Alle disse plattformene har unike egenskaper og forskjellige metoder for presentasjon og håndtering av innhold. 

Problemet med informasjonsflyt til flere kanaler er hva et headless CMS adresserer. Med et headless CMS forblir det strukturerte innholdet det samme, mens hver klient - en app, en enhet eller en nettleser - er ansvarlig for hvordan innholdet presenteres. Utviklere koder vanligvis ikke i headless CMS, men bruker API og kode i et annet rammeverk. 

En ulempe med headless CMS er at de fleste av dem er "cloud native", noe som betyr at de bare er tilgjengelige som skytjenester og ikke som programvare. 

"Headless as a Service" forenkler skalering, overvåking, sikkerhetskopiering osv, men man ofrer fleksibilitet og kontroll. For hver nye klient og enhet må utvikleren håndtere flere utfordringer som for eksempel: 

• URL håndtering (internt og eksternt) 
• Formateringsproblemer og "templating"
• "Caching" og "lazy loading"
• Bruker tilgang
• Feil håndtering
• Synkronisering mellom CMS og klienter
• "Påtvunget" oppdateringer fra skyleverandøren. Kan ikke velge
• Ingen "native previewing" for redaktører
• Ingen trestruktur
• Ingen integrert landingsside editor

Basert på økende etterspørsel av headless CMS har flere tradisjonelle CMS-leverandører lagt til innholds-APIer for å møte konkurransen fra de rene headless leverandørene. Dermed ble hybrid CMS født.

En hybrid CMS kommer med et presentasjonslag, men det er valgfritt å bruke det. 

Mange leverandører hevder å levere hybrid CMS, men tilbudene er veldig forskjellige. Et CMS med API gjør det ikke til et skikkelig hybrid CMS. Viktige aspekter du bør se etter i et hybrid CMS av høy kvalitet er:

• at det er innholdsorientert, snarere enn webside-orientert. Dette betyr at du bør holde deg borte fra løsninger som fokuserer på å bygge sider i stedet for å administrere strukturert innhold. 
• at løsningen støtter håndtering av innehold til ulike media, for eksempel visning av bilder i tilpassede størrelser og formater. 
• at det har dokumenterte API-er med støtte for mange forskjellige programmeringsspråk og tilgang til hele datamodellen.

Nedenfor ser du en sammenligning som skisserer de typiske egenskapene til de tre forskjellige CMS-typene. Det kan være systemer som avviker fra dette, men dette er en generell oversikt.