Headless CMS
Vad är ett headless CMS?
Ett headless CMS är ett Content Management System som separerar innehållshanteringen i backend från frontend, presentationslagret.
Frontend, eller presentationslagret, är allt som en användare ser och interagerar med, traditionellt på en webbplats, men idag på alla enheter med en anslutning till internet. Detta lager innehåller aspekter av en webbplats som bilder, text, layouter etc. Tre vanliga utvecklingsspråk för frontend är HTML, CSS och JavaScript.
Backend är utvecklarens sida av webbplatsen där server-, applikations- och databasinformation hanteras. Därför kontrolleras aspekter av en webbplats som regler, implementatörer och hur sidor är anslutna här. Vanliga utvecklingsspråk för backend är .NET, SQL och Java.
I en headless arkitektur är alltså systemets huvud, eller frontend, avhugget från systemets kropp, eller backend.
Med hjälp av ett headless Content Management System kan du driva olika kundinriktade digitala upplevelser, inklusive native mobilappar, smarta enheter eller befintliga webbapplikationer som inte byggs direkt i själva plattformen.
Skillnaden mellan headless och traditionella Content Management System
Till skillnad från ett traditionellt CMS är front- och backend två helt separata system i ett headless CMS.
Vad är ett traditionellt CMS?
Ett traditionellt CMS kallas också för ett "kopplat" eller "monolitiskt" CMS. Populära CMS-plattformar som använder en kopplad arkitektur är bland annat WordPress och Acquia.
I ett traditionellt CMS är huvudet (eller frontend) och kroppen (eller backend) sammankopplade, och tillsammans hanterar de både innehållet och presentationen av innehållet. Traditionella CMS levereras ofta med en "What You See Is What You Get"-redaktör (eller WYSIWYG). För tydlighetens skull använder vi termen "kopplad" nedan när vi hänvisar till traditionella CMS.
Kopplat CMS vs. decoupled CMS vs. headless CMS
Kopplat, frikopplat och headless är olika former av innehållsleveransarkitekturer. En leveransarkitektur är förhållandet mellan var ditt innehåll hanteras och var det levereras.
Den vanligaste leveransarkitekturen är en kopplad arkitektur där frontend och backend är sammanbundna. I en kopplad arkitektur skapas, hanteras, lagras och levereras innehållet i samma system.
Ett CMS som Optimizely CMS kan användas som en kopplad eller en hybrid CMS-lösning. Många CMS-leverantörer erbjuder bara en av dessa konfigurationer, och det är bra att väga alla för- och nackdelar mot varandra.
Ett decoupled CMS separerar frontend och backend. Innehållet hanteras separat från leveransen. Det förbereds i backend och levereras och presenteras sedan i frontend via API:er. Ett decoupled CMS gör det möjligt för redaktörer, redaktörer och designers att arbeta med frontend medan utvecklarna arbetar med backend.
Slutligen är en headless arkitektur en datakälla med enbart innehåll utan presentationslager. I praktiken är headless bara en annan form av decoupled CMS, men i stället för att CMS:et skickar artefakter till frontend hämtar frontend innehåll från CMS:et.
Det är viktigt att notera att inte alla headless CMS-lösningar är skapade lika. Vissa av dem är rent headless medan andra är en blandning av headless och traditionell arkitektur. Ett renodlat headless-system gör aldrig någon templating och levererar bara rådata till ett annat system. Ett headless hybrid-system kan å andra sidan fungera i en traditionell kopplad arkitektur, men har också verktyg för att servera innehåll headless.
Coupled CMS vs. decoupled CMS vs. headless CMS i korthet
Här är en snabb uppdelning av hur kopplade, frikopplade och headless CMS skiljer sig åt:
| Coupled CMS | Decoupled CMS | Headless CMS |
| Front- och backend är sammankopplade. | Front- och backend är separerade. | Datakälla med enbart innehåll utan presentationslager. |
| Innehållet skapas, hanteras, lagras och levereras i samma system. | Innehållet hanteras separat från innehållsleveransen, vilket gör det möjligt för redaktörer att arbeta på frontend och utvecklare på backend. | I stället för att CMS skickar artefakter till frontend hämtar frontend innehåll från CMS. |
| En enda kanal. | Omnikanal. | Omnikanal. |
Hur headless arkitektur fungerar
En headless lösning är ett CMS som endast använder backend och som är byggt med ett arkiv som kan nås, till exempel via ett RESTful API för visning i flera kanaler. Ett API är en uppsättning regler som gör det möjligt för program att prata med varandra. RESTful eller REST (Representational State Transfer) är en uppsättning regler som utvecklare följer när de skapar API:et. API:er gör att du kan dra in innehåll i presentationslagret och ta emot kommandon från användarna i den headless API:n.
Ett headless CMS har en databas att läsa och skriva innehåll till och ett administrationsgränssnitt där användarna hanterar innehåll. En headless-lösning tillåter endast skapande, läsning, uppdatering och radering av innehåll.
I en headless arkitektur kan utvecklare använda vilket frontend-verktyg som helst för att presentera, återanvända och leverera innehåll till vilken kanal som helst. Separationen av frontend och backend gör det lättare att uppdatera de underliggande systemen oberoende av varandra, bland andra fördelar som vi kommer att ta upp i ett senare avsnitt.
Hur headless content management system kom till
Content Management dök först upp i samband med att statiska webbplatser skapades på 1990-talet, under Web 1.0. Dessa webbplatser var enkla HTML-textfiler. Innehållshanteringen har utvecklats från Perl-skript och platta filer till robusta CMS och till och med sofistikerade DXP:er.
Utvecklingen av headless CMS drevs av den mobila revolutionen, ökningen av publicering i omnikanal och JavaScript.
När mobil teknik och enheter som klockor och röststyrda assistenter blev allt vanligare behövde användarna flexibilitet för att kunna flytta innehåll dit de behövde eller ville, vilket innebar en utmaning för traditionella innehållshanteringssystem.
När jQuery introducerades 2007 blev JavaScript dessutom en rik programmeringsmiljö och idén om att faktiskt skapa mallar för en webbplats i en webbläsare blev verklighet. Utvecklare kunde hämta ren data från servern och skapa en mall för den på kundens webbplats.
Tekniken utvecklas ständigt och formar CMS-landskapet. Eftersom ett headless CMS gör det möjligt för dig att implementera andra tekniker och applikationer när de dyker upp är det en mycket vanlig leveransarkitektur som erbjuds idag.
Är headless CMS rätt för mig?
Idag förespråkar utvecklare ofta headless eftersom de anser att de får mer flexibilitet med en headless-lösning och förstår konsekvenserna av API:er, CDN:er och SDK:er. Men är en headless-lösning verkligen rätt för dig?
I slutändan måste marknadsförare och tekniker bestämma sig för om en headless-lösning kommer att hjälpa deras organisation att täppa till luckorna i kundupplevelsen snabbare, billigare och bättre än befintliga alternativ.
Precis som alla beslut inom teknik har headless arkitekturer fördelar och nackdelar. I slutändan måste du bestämma vad som är rätt för ditt företag.
Tänk på att det finns krav utöver headless som du måste ta hänsyn till när du väljer ett CMS och olika persona som redaktörer, webbplatsadministratörer, utvecklare och marknadsförare som du vill aktivera med ditt CMS. Att köpa teknik för innehåll kan vara en förvirrande process.
Fördelar och nackdelar med ett headless CMS
Ett headless CMS kan integreras med annan teknik, hjälpa dig att nå kunder på nya kontaktpunkter och svara på kundernas förändrade förväntningar. Vi har skrivit om några av fördelarna med headless teknik här, men här är en snabb sammanfattning:
-
Implementeras med annan teknik
Du använder sannolikt dussintals tekniker för att driva olika faser i kundresan. I stället för att spendera hundratusentals dollar på att byta ut dessa äldre system implementerar många företag ett headless CMS som kan implementeras med nuvarande och framtida teknik. En stark headless-innehållsinfrastruktur förenar ditt innehåll och eliminerar åtskilda delar. -
Nå ut till kunderna via nya kontaktpunkter
I takt med att smartklockor och andra smarta hem-enheter blir allt vanligare och mer mogna behöver organisationer ett CMS som kan leverera innehåll till dessa kanaler. Ett headless CMS kan integreras i det underliggande ramverk som används av smarta enheter för att leverera de upplevelser som slutanvändaren förväntar sig. -
Svara på förändrade kundförväntningar
I ett headless CMS skapar tvärfunktionell front-end-kod kontinuitet i användarupplevelsen och gör teoretiskt sett att organisationer snabbare kan leverera på sitt uppdrag, samtidigt som de blir mer lyhörda för förändrade kundförväntningar.
Team som överväger att migrera till en renodlad headless-lösning upptäcker ofta att även om rena headless-lösningar hjälper till att lösa vissa problem, introducerar de också en del nya utmaningar. Om du funderar på att välja en headless-lösning måste du förstå vilka avvägningar och fördelar som finns med detta val.
-
Inte alltid enklare att hantera
Det kan vara tilltalande och enkelt att översätta ditt innehåll till rådata som kan användas av vilken plattform som helst.Men headless löser inte alltid komplexiteten, ofta flyttar det bara runt den. Företag upptäcker ofta att de behöver mer funktionalitet än vad som finns inbyggt i CMS:et, så de måste anpassa det. -
Inte alltid snabbare eller billigare
Väg in tid till värde och den totala ägandekostnaden för alla system du överväger.Att använda ett rent headless CMS kräver att ditt teknikteam tar på sig mer ansvar för att bygga ut olika modeller och mallar. Även om det här tillvägagångssättet ger kontroll och anpassning kan det ta tid att få ett headless system att fungera medan teknikerna samlar in krav, utformar modellerna och modulerna och bygger dem. -
Har inte alltid allt du behöver inbyggt
Rena headless-system saknar ofta funktioner som arbetsflöden eller till och med dra-och-släpp-redigering. Implementeringar misslyckas eftersom de inte har de inbyggda funktionerna. Team måste ofta bygga den funktionalitet som följer med ett traditionellt CMS eller ett hybrid headless CMS. Innehållsskapare kan behöva vänta på teknisk support om de har mer anpassade krav för en ny landningssida som inte stöds av tidigare skapade moduler eller mallar. -
Inte alltid funktionellt för marknadsförare eller affärsanvändare
Eftersom headless tar bort presentationslagret som levereras med applikationen stöder de flesta headless-plattformar inte ledande inbyggda verktyg för affärsanvändare som redigering i kontext eller förhandsgranskning av innehåll före publicering.
Optimizely CMS är headless, hybrid och kopplad, allt-i-ett
Optimizely Content Management System (CMS) har traditionellt varit känt som ett kopplat CMS. Skillnaden mellan detta och ett headless eller decoupled CMS är dock mycket tunnare än vad marknaden vill få dig att tro. Optimizely har alltid kunnat erbjuda en hybrid headless-lösning.
Eftersom vårt CMS hanterar innehåll, och inte webbsidor, är dess innehållsförvar abstraherat från innehållsleveransen. Vårt CMS har en kontinuerlig releasestrategi och en API-first-arkitektur som har hållit jämna steg med utvecklarnas behov, utan att vi har behövt göra fullständiga omskrivningar och ta fram nya produkter för att stödja dagens mångskiftande publik.
Headless CMS positioneras ofta som motsatsen till ett traditionellt webb-CMS. Vårt CMS avvisar denna idé. Faktum är att headless är ett tillägg till vad Optimizely-plattformen normalt gör. Den ena disciplinen är helt enkelt en förlängning av den andra. Och här är varför detta är viktigt: eftersom det finns en naturlig överlappning mellan de två disciplinerna. Optimizely behövde inte bygga ett nytt CMS från grunden - kärnprodukten för webb-CMS är en naturlig, flexibel bas för ett alternativt leveransparadigm.
För att se ett exempel på Optimizelys headless-lösning i aktion, kolla in The Student Hotels berättelse om digital transformation. Med hjälp av ett headless-ramverk har The Student Hotel levererat en blixtsnabb och effektiv webbplats.
Optimizely CMS är headless när du behöver det, och ett fullt utrustat kopplat CMS när du inte behöver det.