3 July 2020

Headless is hip – maar waarom zou je Shopify ontSaaSen?

Headless: wat is het, wat kun je ermee, en waarom geloven wij van CODE niet zo in de hype? Dat gaat onze Algemeen Directeur Wouter je in deze blog uitleggen! Het is een flinke kluif, maar zeker de moeite waard - dus ga er even voor zitten.

Iedereen die een beetje in de e-commerce zit heeft de term al eens voorbij horen komen, want headless is enorm hip op het moment. Wat is het precies? Kort samengevat betekent ‘headless gaan’ dat je de voorkant (de storefront) van je platform – laten we het Shopify noemen ;) - af knipt, en alleen de achterkant (de backoffice) van Shopify gebruikt. Vervolgens vervang je die weggeknipte voorkant door een zelfgebouwde versie.

Een beetje alsof je een auto koopt en de koets niet gebruikt, omdat je zelf een betere hebt ontwikkeld en die wilt gebruiken. We horen je al denken: waarom zou je dat doen? Nou, daar is wel wat voor te zeggen: headless sites zijn vooral supersnel. Maar er zijn ook wat grote nadelen, waarvan de grootste is dat headless sites superduur zijn. Meer daarover kun je in de tweede helft van dit artikel vinden.

Window image widget

Headless = hoge laadsnelheden

Een van de grootste voordelen van headless is de snelheid waarmee je pagina's kunt laden. Nu laadt Shopify ook behoorlijk snel – zeker als je ook nog wat gespecialiseerde tools inzet - maar headless kan nog veel sneller. Headless sites laden precies wat nodig is om de nieuwe pagina te laten zien. Meestal is dit heel weinig en laadt de pagina in een split second.

Dat biedt natuurlijk mogelijkheden om je site zwaarder en complexer te maken, bijvoorbeeld met animaties. Praktische kanttekening: dat klinkt heel aantrekkelijk, totdat je doorkrijgt dat terugkerende klanten die animaties alleen maar irritant vinden, omdat ze – oh ironie – de gebruikerservaring vertragen. Daarvoor heb je natuurlijk geen supersnelle, superdure headless site gebouwd.

Lokalisatie met headless: de voor- en nadelen

Daarnaast wordt headless ingezet om een bekende tekortkoming van de Shopify storefront op te lossen: geen native multilanguage support, wat voor Europese merchants natuurlijk lastig is. Deze merchants werken vaak met een multistore inrichting, waarbij ze voor elk land een eigen store aanhouden.

Met headless kun je wél meerdere talen aanbieden vanuit één enkel storefront, doordat je het content management buiten Shopify doet - meestal in een extern CMS en eventueel een Product Information Manager (PIM).

Daar moeten wij van CODE echter flinke kanttekeningen bij zetten. Headless werkt prima als je een site één op één vertaalt, maar in de praktijk heb je meer nodig dan dat. Verschillende landen hebben namelijk niet alleen een andere taal, maar ook andere gewoonten – vraag maar aan Nederlandse merchants die bijvoorbeeld ook in Duitsland verkopen. One-size-fits-all werkt dan gewoon niet. Je moet dus niet zozeer je site vertalen als wel lokaliseren. ‘Localize, don’t internationalize’ is het credo hier.

Localize, don’t internationalize

.

Elke regio een eigen store, of alles-in-één?

Je store lokaliseren vanuit een enkel storefront is een behoorlijk ingewikkeld gebeuren. OK, je kunt al je content beheren op een enkele plek, maar vervolgens moeten er zoveel extra customizations per regio ingevoerd worden dat het een supercomplex geheel wordt. Naast alle vertalingen (pagina’s, blogs, menu’s, labels, tags en microcopy) moet je namelijk ook nog alle variaties per regio ergens in je code kwijt.

En dan hebben we het nog niet eens over zaken als op de lokale markt gerichte campagnes, lokale betaalmethoden, een lokaal product aanbod en lokale keurmerken. Die zijn allemaal veel eenvoudiger te implementeren in een multistore setup dan in één multiregion shop. Volgens ons is het dus veel slimmer om meerdere simpele stores te bouwen die samen alles kunnen, dan één complexe store die alles kan. Zo kun je de lokale markten overzichtelijk in hun eigen omgeving bedienen.

Zo’n multistore setup is ook waar Shopify (en Shopify partners tools als Klaviyo, Loyalty Lion, PIMs) vanuit gaat bij het verder ontwikkelen van hun software. Zij investeren juist in features die het makkelijker te maken een multistore setup te bedienen, zoals multistore analytics dashboards, multistore staff management, multistore flow management en het snel kunnen kopiëren van bestaande stores.

Wij van CODE weten inmiddels uit ervaring dat meerdere relatief simpele stores makkelijker te managen zijn dan één supercomplexe store tjokvol (dure) ‘business logic’ die nodig is om de site aan te passen aan de locatie van de bezoeker. Daarvoor hoef je dus niet headless te gaan.

Window image widget

De nadelen van headless

Duur, en grote kans op vendor lock-in

OK, headless is dus supersnel, en afhankelijk van je situatie zou het eventueel je multi language issue op kunnen lossen. Wat zijn dan de nadelen? Met stip bovenaan: de kosten van headless.

Wouter legt uit waarom headless – zoals het nu gedaan wordt - enorm in de papieren loopt. “Wat je bij headless eigenlijk doet is dit: je knipt de helft van Shopify eraf, en je bouwt die helft zelf na, met wat extra handige features die Shopify (nog) niet heeft. Dan heb je meteen twee problemen: het kost bakken met geld om het na te bouwen, maar je moet het ook tot het einde der tijden onderhouden!” Wat ook weer bakken met geld kost. Plus: je hebt altijd developers nodig. En daarmee loop je een reëel risico op een ouderwetse vendor lock-in, waarbij je vastzit aan je developer agency en je voor elke wijziging bij hen moet aankloppen. Wil je natuurlijk niet!

Vooral niet als andere Shopify merchants bijna hetzelfde (multi-)storefront hebben zonder daar tonnen extra voor te hoeven betalen, en wat gewoon netjes onderhouden wordt door Shopify. OK, het laadt iets trager, maar er is een hele trukendoos beschikbaar om niet-headless sites te versnellen. Dan is zo’n vendor lock-in natuurlijk lastig uit te leggen, als bureau.

Bij CODE hebben we daarom de filosofie dat je dichtbij je tool moet blijven. Het halve platform vervangen door iets wat er sterk op lijkt past daar natuurlijk voor geen meter bij. Wij proberen juist altijd zo ‘native’ mogelijk te bouwen, zo dichtbij Shopify te blijven als mogelijk is, en dingen zo op te lossen dat ze automatisch meebewegen met Shopify. Hiermee haal je het maximale uit Shopify en ben je ook het meest future-proof, denken wij.

Waarom zou je Shopify ontSaaSen?

En het blijft ook dichtbij de SaaS filosofie: software als een service. Wouter: “Met headless ben je eigenlijk Shopify aan het ontSaaSen.” Je laat een groot stuk Shopify links liggen, herbouwd het, en neemt het in eigen beheer.

Dat is helemaal bizar als je bijvoorbeeld net van een open source platform overgestapt bent naar Shopify. Met headless zit je weer met precies dezelfde issues die je bij open source platforms als Magento ook al niet wilde: je store is veel te complex en daarmee kwetsbaar; jij hebt de volle verantwoordelijkheid als er iets fout gaat; je bent voor alles afhankelijk van developers; en je loopt constant op je tenen om de hogesnelheidstrein die Shopify is bij te houden – elke nieuwe feature of verbetering van hen betekent dat jij weer aan de slag moet om bij te blijven. Alleen hebben zij een enorm leger developers om dat te doen, en jij maar een enkel bureau (en waarschijnlijk een veel beperkter budget).

En dat is nog niet alles: met een headless Shopify setup wordt alles ingewikkelder. De meeste headless setups hebben bijvoorbeeld geen of een beperkte template editor, waardoor je voor de kleinste wijzigingen bij je developers moet aankloppen. Veel van de apps in de Shopify App Store kun je ook niet meer op de gebruikelijke manier installeren: de meeste apps zijn helemaal niet voor headless ontworpen, en kun je in het ergste geval helemaal niet meer gebruiken. Sowieso zul je praktisch alle apps die zichtbaar zijn in de shop, zoals een review app, door een developer moeten laten integreren. En als de app-bouwer de integratie van de app aanpast, zal diezelfde developer weer aan de slag moeten om de app weer werkend te krijgen.

Is dat het wel waard, voor wat je ermee bereikt? En zijn er geen betere, goedkopere oplossingen voor?

Mensen grijpen soms te snel naar automatiseren, terwijl je zonder vaak meer vrijheid hebt.

Wouter

Moet het eigenlijk wel geautomatiseerd?

Kortom, voor CODE voelt de hele headless benadering als een onlogische kunstgreep. Je hebt voor Shopify gekozen omdat je gebruiksgemak wilde (en misschien ook omdat je een trauma hebt van open source), en dan gooi je al dat gemak weer overboord door headless te gaan? Dat is een vrij heftig prijskaartje voor hoge snelheden en alles-op-een-plek.

Wouter: “Mensen grijpen soms te snel naar automatiseren, terwijl je zonder vaak meer vrijheid hebt. De tijdwinst van automatisering wordt ook vaak zwaar overdreven: weegt al die complexiteit wel op tegen die paar manuren die je per maand bespaart? Ken je die oude Russische MiGs? Supergoede gevechtsvliegtuigen. Ik zag ooit een foto van een MiG cockpit: de knoppen allemaal compleet afgesleten van het vele gebruik. Maar ze werkten nog steeds. Dat moet je eigenlijk hebben: simpele, elegante, robuuste ontwerpen. Als iets teveel moeite kost om in de lucht te houden dan is het te fragiel. Elk systeem gaat uiteindelijk naar het punt waar het de minste energie kost en daar blijft het staan. Als je iets probeert te forceren met allerlei kunstgrepen gaat het geheid piepen en kraken.”

Window image widget

Developer’s dream

We zijn ons er wel van bewust dat we hiermee een ander geluid over headless laten horen dan je gewend bent. Want er is nog een derde reden voor de hype, namelijk dat developers headless onwijs cool vinden. Het is het nieuwste speeltje, en voor developers is de techniek van headless sites daarom veel interessanter om mee te werken dan de template engine van Shopify. Zij zullen al snel roepen dat headless beter is: ze willen er graag mee aan de slag.

En dat begrijpen we bij CODE natuurlijk heel goed! Wij zijn tenslotte ook developers! Maar we moeten goed in de gaten houden voor wie we het doen. Zijn onze klanten er ook bij gebaat? Headless heeft zeer waarschijnlijk de toekomst: Google werkt er al mee om je Gmail supersnel te laden, en uiteindelijk is het een efficiëntere architectuur. Het is dan ook te verwachten dat de markt vanzelf meegaat, inclusief Shopify.

Wouter ziet dat wel gebeuren: “In het ideale geval released Shopify zelf een headless framework met een multistore architectuur, zodat je content eenvoudig kan lokaliseren. Daarmee vervallen de nadelen: dan bouwt en onderhoudt Shopify zelf de codebase, waardoor je alle SaaS voordelen behoudt en geen vendor lock-in krijgt. Shopify biedt dan ook de tools aan om deze headless stores eenvoudig uit te kunnen rollen en te managen, zoals ze dit nu ook al met hun huidige template editor doen.”

In het ideale geval released Shopify zelf een headless framework met een multistore architectuur, zodat je content eenvoudig kan lokaliseren.

Wouter

Headless gaan blijft waarschijnlijk nog wel een tijdje hip. Maar wij van CODE vinden: als je het doet, moet je het wel goed doen. Ons advies is: blijf vooral bij de SaaS gedachte en wacht tot Shopify headless gaat.

Wil je weten wat de mogelijkheden zijn voor jouw webshop?

Neem contact op
Waarom je bij CODE wilt werken: veel uitdaging en relaxte sfeer

Waarom je bij CODE wilt werken: veel uitdaging en relaxte sfeer

Geplaatst 5 June 2020 door Linda Blijenberg

Lees meer
CODE presenteert: een custom RMA app om je retourproces te versimpelen

CODE presenteert: een custom RMA app om je retourproces te versimpelen

Geplaatst 8 May 2020 door Linda Blijenberg

Lees meer

Over de auteur

CODE schrijft met gemak 100 regels code per dag, maar een blog is andere koek! Dat laten we dus graag over aan Linda Bleijenberg, onze copywriter. Ze woont om de hoek en wil ook IT-tovenaar worden als ze later groot is. Tot die tijd schrijft ze blogs over wat wij bij CODE allemaal uitspoken.