I världen av att bygga applikationer med hjälp av Content Management Systems (CMS) spelar tre väsentliga ingredienser en nyckelroll:
Se hur innehåll, frontend och backend spelar en nyckelroll i världen av att bygga applikationer med hjälp av Content Management Systems (CMS)
- Innehåll – Det här är det som redaktörer lägger till och justerar – tänk text, bilder, videor och mer.
- Frontend – Det här är hur innehåll visas i olika kanaler, hanterat av frontend-utvecklare med hjälp av ramverk som React eller Vue.
- Backend – Det här är den anpassade funktionalitet som följer med upplevelsen och hanterar saker som ordrar, formulärinlämningar och databasuppdateringar, hanterat av backend-utvecklare.
De tre komponenterna i ett kopplat CMS
I en traditionell kopplad CMS-arkitektur är dessa komponenter vanligtvis buntade tillsammans. Innehållet är tätt kopplat till presentationslagret, vilket gör det svårt att leverera samma innehåll till andra kanaler.
För marknadsförare är detta tillvägagångssätt attraktivt för webbplatser eftersom frontend är „kopplad“ till innehållet, vilket gör redigeringen av webbsidor enkel och snabb. Men så snart behovet av att leverera samma innehåll i andra kanaler uppstår, kör de fast totalt. Innehållet de har redigerat hela tiden är genomsyrat av HTML-taggar bakom kulisserna, vilket är svårt att ta bort när det visas i mobilapplikationer.
De tre komponenterna i ett frikopplat CMS
Det är viktigt att notera att det finns några grader av frikoppling: en som frikopplar mellan komponenterna i en programvara, och en annan som frikopplar mellan helt olika system.
Hybrid-CMS som ett frikopplat CMS
Låt oss först prata om den första typen av frikoppling, som är vanlig i hybrid-CMS:er. Även om innehåll är frikopplat från frontend, lever de fortfarande på samma plats. Detta möjliggörs av programvaruarkitekturer, som MVC (Model-View-Controller), som stöder frikoppling av komponenter inom en applikation.
Figur 1: Även om hybrid-CMS buntar innehåll, frontend och backend tillsammans, är de löst buntade, möjliggjort av mönster som MVC, för att låta innehåll återanvändas av andra frontends och mikrotjänster
I arkitekturdiagrammet ovan lever alla komponenter i CMS:et, men integrationen är lös, vilket gör frontend valfri och innehållet tillgängligt på egen hand för rendering i flera lägen: webb (standard), mobil och kiosk-appar. Frikopplingen sker på programvarunivå, inte på lösningsnivå, vilket vi kommer att gräva i härnäst.
Vilka är fördelarna med ett frikopplat, hybrid-CMS?
- Enkel hantering – Även om denna synvinkel inte gäller alla, vilket vi kommer att fördjupa oss i senare, är verkligheten att vissa företag vars huvudverksamhet inte är teknik eller digitalt tenderar att föredra en strategi med en enda ansvarig leverantör när det gäller det digitala. De föredrar att behålla slimmade team som kan hantera det digitala och engagera så få leverantörer som möjligt med störst täckning: programvara, infrastruktur och dygnet runt-hanterad tjänst med garanti på SLA:er. De vill ha sinnesro utan komplexiteten i att hantera det själva.
- Kostnadseffektivitet – På grund av strategin med en enda ansvarig leverantör drar organisationer ofta nytta av minskade totala ägandekostnader. Att engagera flera leverantörer skapar inte bara komplexitet i den dagliga hanteringen av hela stacken, utan resulterar också ofta i högre totala ägandekostnader, som täcker licenskostnader från flera leverantörer, kostnaden för att integrera dessa lösningar och den extra kostnaden för att lära sig flera leverantörers stackar.
- Användarvänlighet för marknadsförare – ett hybrid-CMS kommer med en frontend, men i form av komponenter som gör det möjligt för marknadsförare att komponera upplevelser, med dra-och-släpp-funktionalitet. Detta är viktigt att lyfta fram eftersom det ibland blir begränsat eller fråntaget marknadsförare i headless CMS-byggen, men vi kommer att diskutera alternativ och lösningar på detta nedan.
Vem och vilka användningsfall passar en frikopplad, hybrid CMS-strategi?
Mindre digitala team, skickliga på ömsesidigt beroende arbete, drar nytta av allt-på-ett-stället-strategin. Den är också idealisk för enklare projekt, som marknadsförings- och broschyrapplikationer, vars primära ansvar är att leverera innehåll till konsumenter över flera kanaler. Om detta är ditt användningsfall, var försiktig så att du inte överkonstruerar din teknikstack eftersom fördelarna kanske inte motiverar den extra komplexiteten. Fokusera i stället på hur du kan göra dina marknadsförare i stånd att röra sig snabbare, hantera stora volymer innehåll och leverera personaliserade budskap till slutanvändare.
Vilka är nackdelarna med en frikopplad, hybrid CMS-arkitektur?
En allt-på-ett-stället-strategi är inte något som lockar företag som har större team och skickliga resurser som vill ha bättre kontroll över sin teknikstack. Här är nackdelarna:
- Tekniska begränsningar på både frontend och backend – Trots frikopplingen vi pratade om måste frontend och backend i slutändan fortfarande driftsättas med CMS:et, vilket skapar begränsningar inom de två komponenterna:
- Backend – dina utvecklare måste använda det backend-programmeringsspråk som ditt CMS är byggt på, som Java eller .NET. Programmeringsspråket och de rätta resurserna blir ett stort övervägande om du satsar på en hybrid CMS-arkitektur.
- Frontend – Även om du kan ha flexibilitet över valet av frontend-ramverk, kommer det att finnas vissa begränsningar kring klientsidesrendering och statisk-webbplatsgenerering som CMS:et kanske inte kan erbjuda, så det är bäst att kontrollera var dessa gränser går med din CMS-leverantör.
- CMS-uppgraderingar kan bli svåra, långdragna och kostsamma – eftersom frontend och backend fortfarande lever med CMS:et kan utvecklare bygga kod som har täta beroenden till versionen av CMS:et. Utvecklare måste säkerställa att de följer bästa praxis för CMS-utveckling för att undvika långdraget och kostsamt arbete med att utföra uppgraderingar.
Som du kommer att se är detta tekniska problem som kan skapa ringeffekter i organisationen. Finns det en bättre lösning?
Frikoppla de tre komponenterna med hjälp av en headless- och mikrotjänstarkitektur.
Som vi nu förstår från ovan är inte alla frikopplade CMS:er headless. Alla headless CMS följer dock en frikopplad strategi; frikoppling på en högre nivå (mellan programvarusystem), till skillnad från en arkitekturnivå inom programvaran.
För att lösa problemen med en hybrid CMS-arkitektur började utvecklare minska CMS:ets ansvarsområde och tog till slut bort frontend och backend helt från CMS:et. Detta minskar ansvaret för CMS-leverantören samtidigt som det ger utvecklare full flexibilitet på frontend och backend, eftersom dessa två komponenter nu hanteras externt.
Vilka är fördelarna med en headless CMS-strategi?
- Ultimat flexibilitet för utvecklare – när frontend- och backend-komponenterna extraheras ur CMS:et blir himlen i princip gränsen. Utvecklare har fullständig valfrihet när det gäller frontend-ramverk, backend-programmeringsspråk, DevOps och hosting av klientsidesapplikationer.
- Kortare upplärningstid för nya utvecklare – eftersom huvudmönstret för integration är genom standardiserade API:er är inträdesbarriären lägre, och därför har nya utvecklare som tas in i teamet en kortare upplärningstid.
- Teknikteamet kan gå till marknaden snabbare – med en fullständig separation av frontend och backend från CMS:et kan frontend-utvecklare arbeta oberoende av backend-utvecklare, vilket skapar ringeffekter i tekniken. Teamet kan gå till marknaden snabbare, uppgraderingar blir snabbare, och utvecklare är mindre beroende av CMS-leverantören.
Vem och vilka användningsfall passar en headless CMS-strategi?
Större teknikteam som föredrar bättre kontroll och hantering av sin teknikstack skulle föredra denna strategi. Applikationer som kräver komplex frontend-funktionalitet eller tvåvägsinteraktivitet, som e-handel eller transaktionstunga applikationer, kommer att dra nytta av denna strategi. Den extra komplexiteten i att hantera flera komponenter motiveras av den extra kontroll och flexibilitet som ingenjörer får från en headless- och mikrotjänstarkitektur.
Vilka är nackdelarna med en headless CMS-strategi?
- Ökad komplexitet och ansvar för tekniken – eftersom frontend och backend inte längre lever i CMS:et måste teknikteam nu tillhandahålla och hantera ny infrastruktur för att hosta dessa komponenter, skapa integrationer och hantera DevOps för att knyta samman dessa komponenter, och säkerställa att SLA:er fortfarande är på plats, inklusive de ytterligare leverantörerna i blandningen. För de enklare användningsfallen som diskuterats ovan kan en överkonstruerad teknikstack faktiskt bromsa dig. Men om ditt användningsfall kräver betydande utvecklingsarbete och du har de rätta tekniska resurserna, är den ökade komplexiteten för bättre kontroll motiverad.
- Högre totala ägandekostnader (TCO) – på grund av de ytterligare komponenterna som behöver licensieras från andra leverantörer, som ytterligare hosting-licens och SLA, samt kostnaden för att integrera dessa, förväntas de totala ägandekostnaderna öka. De extra ägandekostnaderna kan dock kompenseras om detta genererar effektivitet inom teknikavdelningen.
- WYSIWYG-upplevelsen för marknadsförare kan begränsas – medan headless CMS-leverantörer gör det möjligt för redaktörer att hantera innehåll, löser rena headless CMS-leverantörer, genom sin design, inte funktionen för att sätta samman upplevelsen. Utvecklare behöver bygga in denna funktion eller integrera med andra programvaruleverantörer för att få tillbaka WYSIWYG-funktioner för att säkerställa att marknadsföringsupplevelsen inte påverkas.
Slutsats ...
Som med allt teknikrelaterat finns det ingen modell som passar alla. Att välja rätt CMS-arkitektur beror på projektkomplexiteten, teamstorleken och kompetenserna, och den önskade jämvikten mellan enkelhet, kostnad och kontroll. Beslutet måste i slutändan ta hänsyn till flera intressenter: tekniken för bygget, marknadsföringen för innehållsförfattarupplevelsen, och verksamheten för totala ägandekostnader.
Optimizely CMS stöder båda frikopplingsmetoderna: hybrid eller ren headless. I min nästa artikel kommer jag att skriva om det nyligen lanserade Optimizely Graph-erbjudandet som förbättrar vårt API-erbjudande för att skapa effektivitet i programvaruutveckling, så håll utkik här.