De kracht van een headless architectuur

Wij zijn voornamelijk actief in het segment van corporates en de grotere MKB+ klanten (wij noemen dat MKB++). Het digitale landschap binnen dit segment loopt nogal uiteen. Sommige organisaties hebben een heel volwassen digitaal landschap en andere organisaties hebben tot op heden nauwelijks aandacht besteed aan hun digitale omgeving.

Het bepalen van een architectuur is afhankelijk van vele factoren. Zo spelen onder andere de complexiteit van een platform, het al aanwezige digitale landschap en de bestaande infrastructuur hiervan, persoonlijke voorkeuren en (in-house) ontwikkelteams een belangrijke rol. Bij Twentyseven werken wij met verschillende oplossingen en helpen wij onze (toekomstige) klanten in hun keuze voor een architectuur door mee te denken en te adviseren.

Wij zien met regelmaat dat een headless architectuur een prima oplossing is voor onze klanten en projecten. In dit artikel neem ik jullie graag mee in de sterke punten van zo'n architectuur.

Losgekoppeld 

Wij zien vaak dat alle onderdelen van een platform met elkaar verweven zijn. Dit maakt het platform moeilijker te onderhouden en zorgt ervoor dat aanpassingen en uitbreidingen moeilijker te realiseren zijn. In een headless architectuur zijn de presentatie laag, de logica en de content losgekoppeld van elkaar en onafhankelijk van elkaar aan te passen en te updaten.

Content As A Service 

De content wordt beheerd in het content managementsysteem en wordt middels een API laag opgehaald door de presentatielaag, ofwel de zogenoemde ‘head’. Je kunt hierdoor meerdere, verschillende ‘heads’, koppelen aan dezelfde content. Vandaar ook de naam ‘headless’. Er is dus maar één plek waar de content voor verschillende kanalen beheerd wordt. Het ontsluiten van content op deze manier noemen we ook wel Content As A Service.

Content Management 

Het content managementsysteem is in veel gevallen cloud based en veelal ontworpen om ook echt alleen content te beheren. Dit resulteert in een simpelere gebruikers omgeving zonder al te veel opties en instellingen voor de content editor. De focus ligt echt op de content waardoor content editors snel en gemakkelijk content kunnen toevoegen, aanpassen en uitbreiden.

Microservices Architecture 

Er kunnen verschillende externe services geïntegreerd worden die verschillende onderdelen van het landschap afhandelen; denk aan gebruikers management, asset management, product data, vacatures etc. De data vanuit de verschillende services wordt ook weer opgehaald en verwerkt door de ‘head’. Je hoeft dus niet meer het complete platform aan te passen als de organisatie bijvoorbeeld zo groot geworden is dat er een andere service nodig is voor gebruikers management. Hiermee wordt de architectuur ook beter schaalbaar dan traditionele oplossingen.

Geen afhankelijkheden 

De 'head’ wordt geïsoleerd opgezet en is niet afhankelijk van op de server gegenereerde code. Ontwikkelaars kunnen hierdoor frameworks, plugins en tooling inzetten zoals ze bedoeld zijn. Ze hoeven geen workarounds te ontwikkelen of af te wijken van best practices en standaarden. Code wordt beter herbruikbaar en ontwikkelaars kunnen meer tijd besteden aan de kwaliteit van de code.

Performance en gebruikerservaring 

Frameworks en best practices komen de performance van het platform, de UI/UX en daarmee de gebruikerservaring ten goede. Een platform dat gemakkelijk te gebruiken is door de eindgebruiker en goede prestaties levert zal immers resulteren in meer conversie.

Hogere kwaliteit 

De code is kwalitatief hoogwaardig en er zal gemakkelijker geautomatiseerd code getest kunnen worden waardoor de kans op bugs en fouten afneemt. Hoge kwaliteit code en betere unit- en integratie tests zorgen daarnaast voor minder onderhoud.

Gemakkelijker te onderhouden of uit te breiden 

Als er toch onderhoud nodig is, of er moet nieuwe functionaliteit toegevoegd worden, gaat dit gemakkelijker omdat er best practices gevolgd zijn en er geen vreemde workarounds in de code zitten. Daarnaast is het platform gemakkelijker uitbreidbaar en schaalbaar vanwege microservices.

Deployments en hosting 

Deployments zijn over het algemeen minder complex, efficiënter en sneller omdat alleen de 'head’ gedeployed wordt. Deployments zijn dan ook zonder down time en worden per platform (in het geval van multi platform, omni channel) uitgevoerd.

Puntjes van aandacht 

Naast bovengenoemde sterke punten zijn er natuurlijk ook een aantal puntjes van aandacht. Zo is er meer en bredere kennis nodig van met name front-end developers. Er verplaatst best wat logica van de back-end naar de front-end die ontwikkelt moet worden. Ook wordt de front-end complexer qua architectuur en heeft security wat meer aandacht nodig.

Een headless architectuur kan in sommige gevallen wel een paar eisen stellen aan de hosting, maar dat ligt vooral aan de complexiteit van het platform. Moet het platform bijvoorbeeld Server Side Rendering of load-balancing ondersteunen dan heb je veelal meerdere webapps nodig in één hosting omgeving.

Een aantal cloud based content managementsystemen zijn volop in ontwikkeling en bieden nog geen ‘live editor’ aan in hun CMS. Hierdoor ziet een pagina er in het CMS niet zo uit als in de front-end.

Een headless architectuur wordt complexer als er verschillende services gebruikt worden. Ook de bijbehorende prijsmodellen zijn in dat soort gevallen soms wat ondoorzichtig en ook moeten er verschillende licenties beheerd worden.

Meer weten? 

Met dit artikel heb ik geprobeerd duidelijk te beschrijven wat de sterke en minder sterke punten zijn van een headless architectuur. Het inzetten van een dergelijke architectuur is natuurlijk afhankelijk van vele factoren en bij Twentyseven kunnen we helpen met deze keuze voor een al-dan-niet headless setup. Wij helpen je graag verder!