I verden av å bygge applikasjoner ved hjelp av Content Management Systems (CMS) spiller tre vesentlige ingredienser en nøkkelrolle:
Se hvordan innhold, frontend og backend spiller en nøkkelrolle i verden av å bygge applikasjoner ved hjelp av Content Management Systems (CMS)
- Innhold – Dette er det redaktører legger til og justerer – tenk tekst, bilder, videoer og mer.
- Frontend – Dette er hvordan innhold vises på ulike kanaler, administrert av frontend-utviklere ved hjelp av rammeverk som React eller Vue.
- Backend – Dette er den tilpassede funksjonaliteten som følger med opplevelsen, og håndterer ting som ordrer, skjemainnsendinger og databaseoppdateringer, administrert av backend-utviklere.
De tre komponentene i et koblet CMS
I en tradisjonell koblet CMS-arkitektur er disse komponentene vanligvis buntet 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 redigering av nettsider enkelt og raskt. Men så snart behovet for å levere det samme innholdet i andre kanaler oppstår, treffer de en vegg. Innholdet de har redigert hele tiden er gjennomsyret av HTML-tagger bak kulissene, som er vanskelig å fjerne når det vises i mobilapplikasjoner.
De tre komponentene i et frakoblet CMS
Det er viktig å merke seg at det finnes noen grader av frakobling: én som frakobler mellom komponentene i én programvare, og en annen som frakobler mellom helt forskjellige systemer.
Hybrid CMS som et frakoblet CMS
La oss først snakke om den første typen frakobling, som er vanlig i hybride CMS-er. Selv om innhold er frakoblet fra frontend, lever de fortsatt på samme sted. Dette muliggjøres av programvarearkitekturer, som MVC (Model-View-Controller), som støtter frakobling av komponenter innenfor én applikasjon.
Figur 1: Selv om hybrid CMS bunter innhold, frontend og backend sammen, er de løst buntet, muliggjort av mønstre som MVC, for å la innhold gjenbrukes av andre frontends og mikrotjenester
I arkitekturdiagrammet over lever alle komponentene i CMS-et, men integrasjonen er løs, noe som gjør frontend valgfri og innholdet 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 vil grave i neste.
Hva er fordelene med et frakoblet, hybrid CMS?
- Enkel administrasjon – Selv om dette synspunktet ikke gjelder for alle, som vi vil dykke ned i senere, er virkeligheten at noen virksomheter hvis hovedforretning ikke er teknologi eller digitalt, har en tendens til å foretrekke en tilnærming med én leverandør å holde ansvarlig når det gjelder det digitale. De foretrekker å beholde slanke team som kan administrere det digitale, og engasjere færrest mulig leverandører med størst dekning: programvare, infrastruktur og 24/7 administrert tjeneste med garanti på SLA-er. De ønsker ro i sinnet uten kompleksiteten ved å administrere det selv.
- Kostnadseffektivitet – På grunn av tilnærmingen med én leverandør å holde ansvarlig, drar organisasjoner ofte nytte av reduserte totale eierkostnader. Å engasjere flere leverandører skaper ikke bare kompleksitet i den daglige administrasjonen av hele stacken, men resulterer også ofte i høyere totale eierkostnader, som dekker lisenskostnader fra flere leverandører, kostnaden ved å integrere disse løsningene og den ekstra kostnaden ved å lære flere leverandørers stacker.
- Brukervennlighet for markedsførere – et hybrid CMS kommer med en frontend, men i form av komponenter som lar markedsførere komponere opplevelser, med dra-og-slipp-funksjonalitet. Dette er viktig å fremheve fordi dette noen ganger blir begrenset eller fjernet fra markedsførere i headless CMS-bygg, men vi vil diskutere alternativer og løsninger på dette nedenfor.
Hvem og hvilke bruksområder passer en frakoblet, hybrid CMS-tilnærming?
Mindre digitale team, dyktige på gjensidig avhengig arbeid, drar nytte av alt-på-ett-stedet-tilnærmingen. Det er også ideelt for enklere prosjekter, som markedsførings- og brosjyreapplikasjoner, hvis primære ansvar er å levere innhold til forbrukere på tvers av flere kanaler. Hvis dette er ditt bruksområde, vær forsiktig så du ikke overkompliserer teknologistacken din, ettersom fordelene kanskje ikke rettferdiggjør den ekstra kompleksiteten. Fokuser i stedet på hvordan du kan gjøre markedsførerne dine i stand til å bevege seg raskere, levere store mengder innhold og levere personaliserte budskap til sluttbrukere.
Hva er ulempene med en frakoblet, hybrid CMS-arkitektur?
En alt-på-ett-sted-tilnærming er ikke noe som tiltrekker virksomheter som har større team og dyktige ressurser som ønsker bedre kontroll over teknologistacken sin. Her er ulempene:
- Teknologibegrensninger på både frontend og backend – Til tross for frakoblingen vi snakket om, må frontend og backend til syvende og sist fortsatt distribueres med CMS-et, noe som skaper begrensninger innenfor de to komponentene:
- Backend – utviklerne dine må bruke backend-programmeringsspråket CMS-et ditt er bygget på, som Java eller .NET. Programmeringsspråket og de riktige ressursene blir et stort hensyn hvis du går for en hybrid CMS-arkitektur.
- Frontend – Selv om du kan ha fleksibilitet over valget av frontend-rammeverk, vil det være noen begrensninger rundt klientsidegjengivelse og statisk-side-generering som CMS-et kanskje ikke kan tilby, så det er best å sjekke hvor disse grensene er med CMS-leverandøren din.
- CMS-oppgraderinger kan bli vanskelige, langvarige og kostbare – fordi frontend og backend fortsatt lever med CMS-et, kan utviklere bygge kode som har tette avhengigheter til versjonen av CMS-et. Utviklere må sørge for at de følger beste praksis for CMS-utvikling for å unngå langvarig og kostbart arbeid med å utføre oppgraderinger.
Som du vil se, er dette ingeniørproblemer som kan skape ringvirkninger i organisasjonen. Finnes det en bedre løsning?
Frakoble de tre komponentene ved hjelp av en headless- og mikrotjenestearkitektur.
Som vi nå forstår fra ovenfor, er ikke alle frakoblede CMS-er headless. Imidlertid følger alle headless CMS en frakoblet tilnærming; frakobling på et høyere nivå (mellom programvaresystemer), i motsetning til et arkitekturnivå internt i programvaren.
For å løse problemene med en hybrid CMS-arkitektur begynte utviklere å redusere CMS-ets ansvarsområde, og fjernet til slutt frontend og backend helt fra CMS-et. Dette reduserer ansvaret til CMS-leverandøren samtidig som det gir utviklere full fleksibilitet på frontend og backend, ettersom disse to komponentene nå administreres eksternt.
Hva er fordelene med en headless CMS-tilnærming?
- Ultimat fleksibilitet for utviklere – når frontend- og backend-komponentene trekkes ut av CMS-et, blir himmelen i bunn og grunn grensen. Utviklere har full valgfrihet når det gjelder frontend-rammeverk, backend-programmeringsspråk, DevOps og hosting av klientsideapplikasjoner.
- Kortere oppstartstid for nye utviklere – fordi hovedmønsteret for integrasjon er gjennom standardiserte API-er, er inngangsbarrieren lavere, og derfor har nye utviklere som tas inn i teamet en kortere oppstartstid.
- Ingeniørteamet kan gå til markedet raskere – med en fullstendig separasjon av frontend og backend fra CMS-et, kan frontend-utviklere jobbe uavhengig av backend-utviklere, noe som skaper ringvirkninger i ingeniørarbeidet. Teamet kan gå til markedet raskere, oppgraderinger blir raskere, og utviklere er mindre avhengige av CMS-leverandøren.
Hvem og hvilke bruksområder passer en headless CMS-tilnærming?
Større ingeniørteam som foretrekker bedre kontroll og administrasjon av teknologistacken sin, vil foretrekke denne tilnærmingen. Applikasjoner som krever kompleks frontend-funksjonalitet eller toveis interaktivitet, som 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 ingeniører får fra en headless- og mikrotjenestearkitektur.
Hva er ulempene med en headless CMS-tilnærming?
- Økt kompleksitet og ansvar for ingeniørarbeidet – fordi frontend og backend ikke lenger lever i CMS-et, må ingeniørteam nå anskaffe og administrere ny infrastruktur for å hoste disse komponentene, lage integrasjoner og administrere DevOps for å knytte sammen disse komponentene, og sikre at SLA-er fortsatt er på plass, inkludert de ekstra leverandørene i blandingen. For de enklere bruksområdene diskutert ovenfor kan en overkomplisert teknologistack faktisk bremse deg. Men hvis bruksområdet ditt krever betydelig utviklingsarbeid og du har de riktige ingeniørressursene, er den økte kompleksiteten for bedre kontroll rettferdiggjort.
- Høyere totale eierkostnader (TCO) – på grunn av de ekstra komponentene som må lisensieres fra andre leverandører, som ekstra hosting-lisens og SLA, samt kostnaden ved å integrere disse, forventes de totale eierkostnadene å øke. Imidlertid kan de ekstra eierkostnadene oppveies hvis dette genererer effektivitet i ingeniøravdelingen.
- WYSIWYG-opplevelsen til markedsførere kan bli begrenset – mens headless CMS-leverandører gjør det mulig for redaktører å administrere innhold, løser rene headless CMS-leverandører ikke, ved sin design, funksjonen for å sette sammen opplevelsen. Utviklere må bygge inn denne funksjonen eller integrere med andre programvareleverandører for å bringe tilbake WYSIWYG-funksjoner for å sikre at markedsføringsopplevelsen ikke påvirkes.
Konklusjon ...
Som med alt teknologirelatert finnes det ingen modell som passer alle. Å velge riktig CMS-arkitektur avhenger av prosjektkompleksiteten, teamstørrelsen og kompetansen, og den ønskede balansen mellom enkelhet, kostnad og kontroll. Beslutningen må til syvende og sist ta hensyn til flere interessenter: ingeniørarbeid for byggingen, markedsføring for innholdsforfatteropplevelsen, og virksomheten for totale eierkostnader.
Optimizely CMS støtter begge frakoblingsmetodene: hybrid eller ren headless. I min neste artikkel vil jeg skrive om det nylig lanserte Optimizely Graph-tilbudet som forbedrer vårt API-tilbud for å skape effektivitet i programvareutvikling, så følg med her.