Navigere i CMS-arkitekturer på tvers av innhold, frontend og backend

Når man bygger applikasjoner ved hjelp av Content Management Systems (CMS), er det tre viktige ingredienser som spiller en nøkkelrolle:

1. Innhold - Dette er det som redaktørene legger til og justerer - tekst, bilder, videoer og mer.
2. Frontend - Dette er hvordan innholdet vises på ulike kanaler, og administreres av frontend-utviklere som bruker rammeverk som React eller Vue.
3. Backend - Dette er den tilpassede funksjonaliteten som følger med opplevelsen, og som håndterer ting som bestillinger, skjemainnleveringer og databaseoppdateringer, og som administreres av backend-utviklere.

De tre komponentene i et koblet CMS

I en tradisjonell koblet CMS-arkitektur er disse komponentene vanligvis samlet sammen. Innholdet er tett koblet til presentasjonslaget, noe som gjør det vanskelig å levere det samme innholdet til andre kanaler.

For markedsførere er denne tilnærmingen attraktiv for nettsteder fordi frontend er "koblet" til innholdet, noe som gjør det enkelt og raskt å redigere websider. Men så snart behovet for å servere det samme innholdet i andre kanaler oppstår, møter de veggen. Innholdet de har redigert hele tiden, er spekket med HTML-tagger bak kulissene, noe som er vanskelig å fjerne når det skal vises på mobilapplikasjoner.

De tre komponentene i et frikoblet CMS

Det er viktig å merke seg at det finnes flere grader av frikobling: en som frikobler mellom komponentene i én programvare, og en annen som frikobler mellom helt forskjellige systemer.

Hybrid CMS som et frikoblet CMS

La oss først snakke om den første typen frikobling, som er vanlig i hybride CMS-er. Selv om innholdet er frikoblet fra frontend, befinner de seg fortsatt på samme sted. Dette muliggjøres av programvarearkitekturer som MVC (Model-View-Controller), som støtter frikobling av komponenter i én og samme applikasjon.

Figur 1: Selv om Hybrid CMS samler innhold, frontend og backend sammen, er de løst sammenkoblet, noe som muliggjøres av mønstre som MVC, slik at innholdet kan gjenbrukes av andre frontends og mikrotjenester.

I arkitekturdiagrammet ovenfor er alle komponentene i CMS-systemet løst integrert, slik at frontend er valgfri og innholdet er tilgjengelig på egen hånd for gjengivelse i flere moduser: web (standard), mobil og kiosk-apper. Frakoblingen skjer på programvarenivå, ikke på løsningsnivå, som vi skal se nærmere på i neste avsnitt.

Hva er fordelene med et frikoblet, hybrid CMS?

1. Enkel administrasjon - Selv om dette synspunktet ikke gjelder for alle, noe vi skal komme nærmere inn på senere, er det slik at enkelte bedrifter som ikke har teknologi eller digitale tjenester som hovedvirksomhet, foretrekker en "en hals til halsen"-tilnærming når det gjelder digitale tjenester. De foretrekker å beholde slanke team som kan håndtere det digitale og engasjere færrest mulig leverandører som har den største dekningen: programvare, infrastruktur og 24/7 managed service med SLA-garanti. De ønsker trygghet uten å måtte administrere det selv.
2. Kostnadseffektivitet - På grunn av one-throat-to-choke-tilnærmingen drar organisasjoner ofte nytte av reduserte totale eierkostnader. Å engasjere flere leverandører skaper ikke bare kompleksitet i den daglige administrasjonen av hele stakken, men resulterer også ofte i en høyere total eierkostnad, som dekker lisenskostnader fra flere leverandører, kostnadene ved å integrere disse løsningene og den ekstra kostnaden ved å lære seg flere leverandørstabler.
3. Brukervennlighet for markedsførere - et hybrid-CMS leveres med en frontend, men i form av komponenter som gjør det mulig for markedsførere å komponere opplevelser ved hjelp av dra-og-slipp-funksjonalitet. Dette er viktig å fremheve fordi dette noen ganger blir forkrøplet eller tatt bort fra markedsførere i hodeløse CMS-konstruksjoner, men vi vil diskutere alternativer og løsninger på dette nedenfor.

Hvem og hvilke bruksområder egner seg for en frikoblet, hybrid CMS-tilnærming?

Mindre digitale team som er dyktige til å jobbe med gjensidig avhengighet, drar nytte av one-stop-tilnærmingen. Det er også ideelt for enklere prosjekter, for eksempel markedsførings- og brosjyreprogrammer, der hovedansvaret er å levere innhold til forbrukerne på tvers av flere kanaler. Hvis dette er ditt bruksområde, bør du være forsiktig med å overutvikle den tekniske stakken, da fordelene kanskje ikke rettferdiggjør den ekstra kompleksiteten. Fokuser i stedet på hvordan du kan gjøre markedsførerne dine i stand til å handle raskere, levere store mengder innhold og levere tilpassede meldinger til sluttbrukerne.

Hva er ulempene med en frikoblet, hybrid CMS-arkitektur?

En one-stop shop-tilnærming er ikke noe som tiltrekker seg bedrifter som har større team og dyktige ressurser som ønsker bedre kontroll over den tekniske stakken. Her er ulempene:

1. Teknologibegrensninger på både frontend og backend - Til tross for frikoblingen vi snakket om, må frontend og backend til syvende og sist fortsatt distribueres sammen med CMS-et, noe som skaper begrensninger i de to komponentene:
2. Backend - utviklerne dine må bruke det programmeringsspråket som CMS-et bygger på, for eksempel Java eller .NET. Programmeringsspråket og de riktige ressursene blir en viktig faktor hvis du velger en hybrid CMS-arkitektur.
3. Frontend - Selv om du kan ha fleksibilitet når det gjelder valg av frontend-rammeverk, vil det være noen begrensninger når det gjelder rendering på klientsiden og generering av statiske sider som CMS-et kanskje ikke kan tilby, så det er best å sjekke hvor disse grensene går med CMS-leverandøren din.
4. CMS-oppgraderinger kan bli vanskelige, langvarige og kostbare - fordi frontend og backend fortsatt lever med CMS, kan utviklere bygge kode som er svært avhengig av CMS-versjonen. Utviklerne må sørge for at de følger beste praksis for CMS-utvikling for å unngå langvarige og kostbare oppgraderinger.

Som du vil se, er dette tekniske problemer som kan skape ringvirkninger i organisasjonen. Finnes det en bedre løsning?

Koble fra de tre komponentene ved hjelp av en headless- og mikrotjenestearkitektur.

Som vi nå forstår, er ikke alle frikoblede CMS-er hodeløse. Men alle headless CMS følger en frakoblet tilnærming; frakobling på et høyere nivå (mellom programvaresystemer), i motsetning til et arkitekturnivå i programvaren.

For å løse problemene med en hybrid CMS-arkitektur har utviklerne begynt å dekomponere CMS-ansvaret, og til slutt fjerne frontend og backend helt fra CMS. Dette reduserer CMS-leverandørens ansvar, samtidig som utviklerne får full fleksibilitet når det gjelder frontend og backend, ettersom disse to komponentene nå administreres eksternt.

Hva er fordelene med en headless CMS-tilnærming?

1. Ultimativ fleksibilitet for utviklere - når frontend- og backend-komponentene trekkes ut av CMS-systemet, er det egentlig bare fantasien som setter grenser. Utviklerne har full valgfrihet når det gjelder frontend-rammeverk, backend-programmeringsspråk, devOps og hosting av applikasjoner på klientsiden.
2. Kortere oppstartstid for nye utviklere - fordi hovedmønsteret for integrasjon er gjennom standardiserte API-er, er inngangsbarrieren lavere, og nye utviklere som tas inn i teamet, har derfor kortere oppstartstid.
3. Ingeniørene kan komme raskere ut på markedet - med et fullstendig skille mellom frontend og backend i CMS-systemet kan frontend-utviklerne jobbe uavhengig av backend-utviklerne, noe som skaper ringvirkninger i ingeniørarbeidet. Teamet kan komme raskere ut på markedet, oppgraderingene går raskere, og utviklerne er mindre avhengige av CMS-leverandøren.

Hvem og hvilke bruksområder egner seg for en headless CMS-tilnærming?

Større utviklingsteam som foretrekker bedre kontroll og styring av den tekniske stakken, vil foretrekke denne tilnærmingen. Applikasjoner som krever kompleks frontend-funksjonalitet eller toveis interaktivitet, for eksempel e-handel eller transaksjonstunge applikasjoner, vil dra nytte av denne tilnærmingen. Den ekstra kompleksiteten ved å administrere flere komponenter rettferdiggjøres av den ekstra kontrollen og fleksibiliteten som ingeniører får med en headless- og mikrotjenestearkitektur.

Hva er ulempene med en headless CMS-tilnærming?

1. Økt kompleksitet og ansvar for ingeniørene - fordi frontend og backend ikke lenger ligger i CMS-et, må ingeniørteamene nå klargjøre og administrere ny infrastruktur for å være vert for disse komponentene, opprette integrasjoner og administrere DevOps for å knytte disse komponentene sammen, og sørge for at SLA-er fortsatt er på plass, inkludert de ekstra leverandørene som er med i miksen. For enklere brukstilfeller som diskutert ovenfor, kan en overkonstruert teknisk stabel faktisk gjøre deg tregere. Men hvis brukstilfellet ditt krever betydelig utviklingsarbeid og du har de riktige tekniske ressursene, kan den økte kompleksiteten for å få bedre kontroll være berettiget.
2. Høyere totale eierkostnader (TCO) - på grunn av de ekstra komponentene som må lisensieres fra andre leverandører, for eksempel ekstra hostinglisenser og SLA, samt kostnadene for å integrere disse, forventes det at de totale eierkostnadene øker. De økte totale eierkostnadene kan imidlertid oppveies av effektiviseringsgevinster i utviklingsavdelingen.
3. WYSIWYG-opplevelsen til markedsførere kan bli forkrøplet - selv om headless CMS-leverandører gjør det mulig for redaktører å administrere innhold, løser ikke rene headless CMS-leverandører muligheten til å sette sammen opplevelsen. Utviklere må bygge inn denne muligheten eller integrere med andre programvareleverandører for å få tilbake WYSIWYG-funksjonene for å sikre at markedsføringsopplevelsen ikke blir påvirket.

Konklusjon

Som med alt annet som har med teknologi å gjøre, finnes det ingen modell som passer for alle. Valg av riktig CMS-arkitektur avhenger av prosjektets kompleksitet, teamets størrelse og kompetanse, samt ønsket balanse mellom enkelhet, kostnader og kontroll. Til syvende og sist må avgjørelsen ta hensyn til flere interessenter: Ingeniørene må ta hensyn til byggingen, markedsavdelingen må ta hensyn til opplevelsen av å skrive innhold, og virksomheten må ta hensyn til de totale eierkostnadene.

Optimizely CMS støtter begge frikoblingsmetodene: hybrid eller ren headless. I min neste artikkel vil jeg skrive om det nylanserte Optimizely Graph-tilbudet som forbedrer API-tilbudet vårt for å skape effektivitet i programvareutviklingen, så følg med her.