Slik fungerer headless-arkitektur
En headless-løsning er et backend-only CMS bygget med et repository 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 å kommunisere med hverandre. RESTful eller REST (Representational State Transfer) er et sett med regler som utviklere følger når de lager API-et. API-er lar deg hente innhold inn i presentasjonslaget og motta kommandoer fra brukerne inn i headless-applikasjonen.
Et headless CMS har en database for å lese og skrive innhold til, og et administrasjonsgrensesnitt der brukere administrerer innhold. En headless-løsning tillater bare oppretting, lesing, oppdatering og sletting av innhold.
I en headless-arkitektur kan utviklere bruke ethvert frontend-verktøy for å presentere, gjenbruke og levere innhold til hvilken som helst kanal. Separasjonen av frontenden og baksiden gjør det enklere å oppdatere de underliggende systemene uavhengig av hverandre, blant andre fordeler som vi vil dekke i en senere seksjon.
Hvordan headless innholdsstyringssystemer oppstod
Innholdsstyring oppstod med skapelsen av 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 headless CMS ble drevet av den mobile revolusjonen, oppstigningen av omnikanalpublisering og levedyktigheten til JavaScript.
Da mobilteknologi og enheter som smartklokker og stemmeaktiverte assistenter steg frem, trengte brukerne fleksibiliteten til å sende innhold dit de trengte eller ønsket det, noe som presenterte en utfordring for tradisjonelle innholdsstyringssystemer.
I tillegg, da jQuery ble introdusert i 2007, ble JavaScript et rikt programmeringsmiljø og ideen om faktisk å lage maler for et nettsted i en nettleser oppstod. Utviklere var i stand til å hente rene data fra serveren og lage maler for det i klientens nettsted.
Teknologi er i konstant utvikling og former CMS-landskapet. Fordi et headless CMS gjør det mulig å integrere med andre teknologier og applikasjoner etter hvert som de dukker opp, er det en svært vanlig leveringsarkitektur som tilbys i dag.
Er headless CMS riktig for meg?
I dag presser utviklere ofte på for headless fordi de mener de får mer fleksibilitet fra en headless-løsning og forstår implikasjonene 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 teknologifolk bestemme om en headless-løsning vil hjelpe organisasjonen deres med å lukke hullene i kundeopplevelsen raskere, billigere og bedre enn eksisterende alternativer.
Som enhver beslutning innen teknologi har headless-arkitekturer fordeler og ulemper. Til syvende og sist må du bestemme hva som er riktig for din virksomhet.
Husk at det er krav utover headless som du vil vurdere når du velger et CMS, og ulike personas som innholdsredaktører, nettstedsadministratorer, utviklere og markedsførere som du vil aktivere med ditt CMS. Å kjøpe innholdsteknologi kan være en forvirrende prosess.
Fordeler vs. ulemper med et headless CMS
Et headless CMS kan integreres med annen teknologi, hjelpe deg med å nå kunder på nye kontaktpunkter og reagere 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 opererer sannsynligvis dusinvis av teknologier for å drive ulike faser i kundereisen. I stedet for å bruke hundretusenvis av kroner på å bytte ut disse eldre systemene, implementerer mange selskaper et headless CMS som integreres med nåværende og fremtidig teknologi. En sterk headless innholdsinfrastruktur vil forene innholdet ditt og eliminere siloer.
-
Nå kunder på nye kontaktpunkter
Ettersom smartklokker og andre smarthusenheter vokser i adopsjon og modenhet, trenger organisasjoner et CMS som kan levere innhold til disse kanalene. Et headless CMS kan integreres med det underliggende rammeverket som brukes av smarte enheter for å levere de opplevelsene sluttbrukeren forventer.
-
Reager på endrede kundeforventninger
I et headless CMS skaper tverrfunksjonell frontend-kode kontinuitet i brukeropplevelsen og gjør teoretisk sett organisasjoner raskere til å levere på sitt oppdrag, samtidig som de gjøres 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 hjelper med å løse noen problemer, introduserer de også noen nye utfordringer. Hvis du vurderer å gå med en headless-løsning, må du forstå kompromissene og fordelene ved dette valget.
-
Ikke alltid enklere å administrere
Det kan virke innledningsvis tiltalende og enkelt å oversette innholdet ditt til rå data som konsumeres av enhver plattform. Headless løser imidlertid ikke alltid kompleksitet, ofte bare flytter det den rundt. Selskaper oppdager ofte at de trenger mer funksjonalitet enn det som er innebygd i CMS-et, så de må tilpasse.
-
Ikke alltid raskere eller billigere
Vei verdiskapingstiden og totalkostnadene ved eierskap for alle systemer du vurderer. Å ta i bruk et rent headless CMS krever at ingeniørteamet ditt tar på seg mer ansvar for å bygge ut ulike modeller og maler. Selv om denne tilnærmingen gir kontroll og tilpasning, kan det ta tid å få et headless-system opp og gå mens ingeniørteamet samler krav, designer modeller og moduler og bygger dem.
-
Har ikke alltid alt du trenger innebygd
Rene headless-systemer mangler ofte funksjoner som arbeidsflyter eller til og med dra-og-slipp-redigering. Implementeringer mislykkes fordi de ikke har de innebygde funksjonene. Team må ofte bygge funksjonaliteten som følger med et tradisjonelt CMS eller et hybrid headless CMS. Innholdsskapere kan trenge å vente på ingeniørstø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 sendes med applikasjonen, støtter de fleste headless-plattformer ikke ledende native forretningsbrukerverktøy som redigering i kontekst eller forhåndsvisning av innhold før publisering.
Optimizely CMS er headless, hybrid og koblet – alt i ett
Optimizely innholdsstyringssystem (CMS) har tradisjonelt vært kjent som et koblet CMS. Imidlertid er skillet mellom dette og et headless eller frakoblet CMS mye tynnere enn markedet vil ha deg til å tro. Optimizely har alltid vært i stand til å tilby en hybrid headless-løsning.
Fordi CMS-et vårt administrerer innhold, og ikke nettsider, er innholdsrepositoriet abstrahert fra innholdsleveringen. CMS-et vårt har en kontinuerlig utgivelsesstrategi og en API-first-arkitektur som har holdt tritt med utviklerbehov, uten at vi har ty til komplette omskrivninger og nye produkter for å støtte dagens mangfoldige publikum.
Headless CMS er ofte posisjonert som det motsatte av et tradisjonelt web-CMS. CMS-et vårt avviser denne ideen. Faktisk er headless i tillegg til det Optimizely-plattformen normalt gjør. En disiplin er rett og slett en utvidelse 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 – kjerne-web-CMS-produktet er en naturlig, fleksibel base for et alternativt leveringsparadigme.
For å se et eksempel på Optimizelys headless-løsning i aksjon, sjekk ut The Student Hotels historie om digital transformasjon. Ved å bruke et headless-rammeverk har The Student Hotel levert et lynraskt og effektivt nettsted.
Optimizely CMS er headless når du trenger det, og et fullt utstyrt koblet CMS når du ikke gjør det.
