Hur headless-arkitektur fungerar
En headless-lösning är ett backend-only CMS byggt med ett repository som kan nås, exempelvis, 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 kommunicera 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 det möjligt att hämta innehåll till presentationslagret och ta emot kommandon från användare i headless-applikationen.
Ett headless CMS har en databas för att läsa och skriva innehåll till, och ett administrationsgränssnitt där användare hanterar innehåll. En headless-lösning tillåter bara 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 innehållshanteringssystem uppstod
Innehållshantering uppstod med skapandet av statiska webbplatser på 1990-talet, under Web 1.0. Dessa webbplatser var enkla HTML-textfiler. Innehållshantering har utvecklats från Perl-skript och platta filer till robusta CMS-erbjudanden och till och med sofistikerade DXP:er.
Utvecklingen av headless CMS drevs av den mobila revolutionen, uppgången av omnikanalpublicering och JavaScripts livskraft.
När mobil teknik och enheter som smartklockor och röststyrda assistenter steg fram behövde användarna flexibiliteten att skicka innehåll dit de behövde eller ville, vilket skapade en utmaning för traditionella innehållshanteringssystem.
Dessutom, när jQuery introducerades 2007, blev JavaScript en rik programmeringsmiljö och idén om att faktiskt mallninga en webbplats i en webbläsare uppstod. Utvecklare kunde hämta ren data från servern och mallninga den i klientens webbplats.
Tekniken utvecklas ständigt och formar CMS-landskapet. Eftersom ett headless CMS gör det möjligt att integrera med andra tekniker och applikationer allt eftersom de dyker upp är det en mycket vanlig leveransarkitektur som erbjuds idag.
Är ett headless CMS rätt för mig?
Idag driver utvecklare ofta på för headless eftersom de tror att de får mer flexibilitet från 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 behöver marknadsförare och teknikproffs avgöra om en headless-lösning kommer att hjälpa deras organisation att stänga 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 din verksamhet.
Tänk på att det finns krav utöver headless som du vill överväga när du väljer ett CMS och olika personas som innehållsredaktörer, webbplatsadministratörer, utvecklare och marknadsförare som du vill aktivera med ditt CMS. Att köpa innehållsteknik kan vara en förvirrande process.
Fördelar vs. nackdelar med ett headless CMS
Ett headless CMS kan integrera med annan teknik, hjälpa dig att nå kunder på nya kontaktpunkter och svara på förändrade kundförväntningar. Vi skrev om några av fördelarna med headless-teknik här, men här är en snabb sammanfattning:
-
Integrera med annan teknik
Du driver troligtvis dussintals tekniker för att driva olika faser i kundresan. Istället för att spendera hundratusentals kronor på att byta ut dessa äldre system implementerar många företag ett headless CMS som integreras med nuvarande och framtida teknik. En stark headless-innehållsinfrastruktur kommer att ena ditt innehåll och eliminera silos.
-
Nå kunder på nya kontaktpunkter
Eftersom smartklockor och andra smarta hemenheter expanderar i adoption och mognad behöver organisationer ett CMS som kan leverera innehåll till dessa kanaler. Ett headless CMS kan integrera med det underliggande ramverket som används av smarta enheter för att leverera de upplevelser slutanvändaren förväntar sig.
-
Svara på förändrade kundförväntningar
I ett headless CMS skapar tvärfunktionell frontend-kod kontinuitet i användarupplevelsen och gör teoretiskt sett organisationer snabbare i att leverera på sitt uppdrag, samtidigt som det gör dem mer lyhörda för förändrade kundförväntningar.
Team som överväger att migrera till en ren headless-lösning upptäcker ofta att även om rena headless-lösningar hjälper till att lösa vissa problem, introducerar de också nya utmaningar. Om du överväger att gå med en headless-lösning behöver du förstå kompromisserna och fördelarna med detta val.
-
Inte alltid enklare att hantera
Det kan inledningsvis verka tilltalande och enkelt att översätta ditt innehåll till rådata som konsumeras av vilken plattform som helst. Headless löser dock inte alltid komplexitet, ofta bara flyttar det den. Företag finner ofta att de behöver mer funktionalitet än vad som är inbyggt i CMS:et, så de måste anpassa.
-
Inte alltid snabbare eller billigare
Väg time-to-value och den totala ägandekostnaden för alla system du överväger. Att anta ett rent headless CMS kräver att ditt ingenjörsteam tar på sig mer ansvar för att bygga ut olika modeller och mallar. Även om detta tillvägagångssätt ger kontroll och anpassning kan det ta tid att få ett headless-system upp och igång medan ingenjörsteamet samlar krav, designar modeller och moduler 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 medföljer ett traditionellt CMS eller hybridt headless CMS. Innehållsskapare kan behöva vänta på ingenjörsstöd 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 affärsanvändarverktyg som kontextredigering eller förhandsgranskning av innehåll innan publicering.
Optimizely CMS är headless, hybrid och kopplat – allt i ett
Optimizely innehållshanteringssystem (CMS) har traditionellt sett varit känt som ett kopplat CMS. Distinktionen mellan detta och ett headless eller frikopplat CMS är dock mycket tunnare än marknaden vill låta dig tro. Optimizely har alltid kunnat erbjuda en hybrid headless-lösning.
Eftersom vårt CMS hanterar innehåll, och inte webbsidor, är dess innehållsrepository 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 utvecklarbehov, utan att vi behövt ta till fullständiga omskrivningar och nya produkter för att stödja dagens mångfaldiga 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. En disciplin är helt enkelt en utvidgning av den andra. Och här är varför detta är viktigt: för det finns en naturlig överlappning mellan de två disciplinerna. Optimizely behövde inte bygga ett nytt CMS från grunden – kärn-webb-CMS-produkten är en naturlig, flexibel bas för ett alternativt leveransparadigm.
För att se ett exempel på Optimizelys headless-lösning i praktiken, kolla in The Student Hotels berättelse om digital transformation. Genom att utnyttja 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 gör det.
