Is headless commerce écht waardevol of een zoveelste buzzword?

Wie de vele artikelen over headless commerce leest, kan bijna niet om de voordelen heen. Het roept de vraag op of er sprake is van een zoveelste buzzword of dat deze technische keuze werkelijk waarde biedt. Voor wie en in welke situaties is headless commerce de beste toepassing?

Als zelfs niet-techneuten zich bezighouden met de architectuur van een e-commercesysteem, dan  moet headless commerce wel een zekere bedrijfsmatige relevantie in zich dragen. Die gedachte komt niet geheel uit de lucht vallen. Front-ends, de voor de gebruiker zichtbare weergave, ontwikkelen snel en komen in het middelpunt van de belangstelling te staan. De interactie met de gebruiker zorgt immers voor differentiatie en daarmee voor omzet. Met het groeiende aantal digitale touchpoints en het inzicht dat bedrijven hun customer journey’s hiervoor moeten optimaliseren, beweegt de e-commercetechnologie mee.

De scheiding van front- en back-end

Anders dan in een traditioneel e-commerceplatform zijn in een headless architectuur de front-end en back-end van elkaar gescheiden. De twee zijn via API’s (application programming interface) met elkaar verbonden. Zo is de zichtbare schil per touchpoint in te richten en optimaliseren en levert de back-end de logica en e-commercefunctionaliteiten.

De ontkoppeling van de beide lagen zorgt ervoor dat de back-end zich onafhankelijk van de context of presentatievorm kan bezighouden met de uitlevering van opgevraagde ruwe data. Als een mobiele app een categorie met producten toont is op de achtergrond een lijst opgeroepen – via een REST API of met het snellere alternatief GraphQL. Voor de back-end maakt het niet uit of de aanvraag van deze data afkomstig is van de genoemde app, een smarthome applicatie zoals Alexa of een chatbot.

Dit kan wat abstract overkomen, maar heeft hele duidelijke praktische voordelen. Waar een back-end doorgaans een levensduur heeft van vijf tot tien jaar, verouderen front-ends veel sneller. UX-designs die in het begin innovatief en fris leken, kunnen bij de lancering al suf en verouderd aanvoelen. In de praktijk onderwerpen de grotere webshops hun interface dan ook elke twee jaar aan een grafische update. De e-commercemanager kan zich in zo’n geval beperkt voelen en gedwongen worden een compleet nieuw systeem te omarmen, terwijl de back-end nog voldoet. Tegen die achtergrond is het erg praktisch om de front-end en back-end als twee aparte onderdelen te behandelen. Het totale systeem wint aan flexibiliteit.

Headless in de praktijk

Doorgaans zijn er twee belangrijke impulsen om een headless project te starten: het verbinden van een content management systeem (CMS) en de ontwikkeling van een mobiele front-end. 

CMS en DXP

CMS-systemen – tegenwoordig vaak ook Digital Experience Platforms genoemd – worden gebruikt om content te publiceren en hebben over het algemeen een praktische oplossing voor het managen van media (foto en video) en een slimme manier om de inhoud te verspreiden. Vooral bedrijven die hun merken aantrekkelijk willen presenteren gaan hiervoor. Is er gekozen voor een headless architectuur, dan hoeft het bedrijf slechts een e-commercesysteem te integreren om ook online te kunnen verkopen. Door de front-end zo aan te passen dat deze door middel van API-calls data uit de e-commerce back-end oproept, zijn de belangrijkste winkelfunctionaliteiten toegevoegd. Aanbieders zoals Magnolia en Bloomreach hebben online vele ‘best practices’ beschikbaar die laten zien hoe content en e-commerce goed samensmelten.

SPA’s en PWA’s

Een andere belangrijke aanleiding is het groeiende belang van de mobiele consument. Was een responsive design voorheen nog voldoende, inmiddels vragen klanten om betere en snellere toepassingen die doen denken aan hun ervaringen met native apps. Voor veel bedrijven bieden Single Page Applications (SPA’s) of Progressive Web Apps (PWA’s) het antwoord. Technisch gezien worden HTML en CSS gemengd met dynamische Javascriptonderdelen om zo het beste van twee werelden te bieden: SPA’s en PWA’s reageren net zo snel als een native app en zijn ook offline te gebruiken, maar gebruikers hoeven ze niet via een appstore te downloaden. Ook hierin is de headless architectuur interessant: een SPA of PWA vraagt slechts om de toelevering van data uit een ander systeem. Basistechnologieën zoals Angular, React en Vue.js doen de rest.

Wat betekent dit voor e-commerceplatforms?

Net als wijzelf herkennen de meeste leveranciers van e-commerceplatforms de groeiende populariteit van headless en manifesteren zich dan ook duidelijker op dit vlak. Er zijn bijvoorbeeld systemen die zich positioneren als ‘native headless’: commercetools en Elastic Path (en contentful en Contentstack op het vlak van CMS) presenteren zich als API-first en leveren geen eigen front-end mee. Ook Spryker maakt deze technologische keuze, maar niet als cloudoplossing. Het lastige is dat headless geen beschermd begrip is en vele interpretaties kent. Alle marktpartijen die een API aanbieden noemen zich inmiddels ‘headless vriendelijk’.

Headless infrastructuur

Voor gebruikers is dit niet per se slecht. Zolang de systemen de juiste verbindingsmogelijkheden aanbieden, zijn ze te gebruiken voor het ontwikkelen van een headless infrastructuur. Je zou daarmee kunnen zeggen dat headless niet het kenmerk is van een platform, maar eerder een bedrijfsmatige keuze. Platformen die van origine een volledig geïntegreerde oplossing bieden – Adobe Commerce Cloud (voorheen Magento), Intershop, OXID eShop, Shopware (vooral sinds versie 6) en Shopify (Plus) vind je daarom steeds vaker terug in headless projecten.

Het Nederlandse bureau Ask Phill koos bijvoorbeeld recent zo’n architectuur voor de ontwikkeling van de internationale webshop van STOX Energy. Ask Phill combineerde de back-end van Shopify Plus met het gespecialiseerde CMS Contentful. Het grote voordeel van deze opzet is dat STOX Energy daardoor de storefront in diverse talen kan beheren vanuit één dashboard, de SEO-structuur meer flexibiliteit heeft en de mobiele performance van Shopify Plus te optimaliseren is. Zeker voor e-commercebedrijven met specifieke wensen neemt hierdoor de wendbaarheid toe.

Dus: headless of niet?

Voor veel scenario’s bieden geïntegreerde oplossingen zoals Magento voldoende mogelijkheden. Bedrijven kunnen hun schaalbare digitale bedrijfsmodel ook prima vormgeven binnen het raamwerk van de front-end templates van OXID, Shopware en Shopify. Is er eenmaal de behoefte om informatie op een andere wijze te presenteren, dan zorgt een API voor allerlei opties zonder daarvoor eerst volledig headless te werken.

Er zijn natuurlijk situaties of bedrijfsmodellen die wel om een headless architectuur vragen. Bijvoorbeeld wanneer een bedrijf al werkt met een CMS of DXP en daar achteraf e-commercefunctionaliteiten aan wil toevoegen. Of wanneer je als merk volledige controle wil over de front-end en met enig gemak een innovatief touchpoint zoals ‘in-car commerce’ wil toevoegen. Wat erg belangrijk is om in gedachten te houden, is dat de extra kosten, langere ontwikkeltijden complexiteit van headless projecten moeten opwegen tegen de eerder genoemde voordelen.

Op het eerste gezicht belooft headless veel voordelen. Tegelijkertijd moet je je altijd blijven afvragen of het middel in verhouding staat tot de resultaten. Op de juiste manier ontwikkeld en onderhouden biedt een headless architectuur voordelen. Daar staat tegenover dat een slechte implementatie of onervaren team van headless commerce eerder een rem dan gaspedaal maken.

Over de auteur: Mel van Lieshout is country manager Nederland bij Shopify.