Headless WooCommerce – e-Commerce zonder kopzorgen!

Voor je verder leest…

Dit artikel is een vervolg op een tweetal andere artikelen, namelijk op het artikel over ‘Headless WordPress‘ en het artikel over ‘WooCommerce – The Next Generation‘. Om dit artikel volledig te begrijpen, adviseer ik je eerst kennis te nemen van deze twee blogposts.

… en dan begrijp je nu waarschijnlijk ook wat er met ‘Headless WooCommerce’ bedoeld wordt.

Monolitische Internet toepassingen zoals bijvoorbeeld WordPress hebben hun langste tijd gehad. Wanneer je daarbij in aanmerking neemt dat WordPress al sinds 2003 bestaat, is dat niet een directe reden tot paniek, maar voor jouw lange termijn strategie is het goed om ook na te denken over ‘Life after WordPress’ en ‘Life after WooCommerce’.

Een ‘headless WordPress’ of een ‘headless WooCommerce’ is niet zomaar een kreet die uit het niet naar boven komt, het is een serieuze toepassing om jouw WordPress website of jouw WooCommerce webshop ook toekomstvast te krijgen.

Betekent dit dan dat je vandaag de dag niet meer met WordPress of WooCommerce moet beginnen? Absoluut niet. Maar het wil wel zeggen, dat je in jouw planning voor de komende jaren rekening moet houden met een transitie naar een ander platform.

Wanneer je start als ondernemer dan is WordPress (inclusief WooCommerce of een online leeromgeving) nog steeds de voordeligste, snelste en makkelijkste start die je kan maken. Heb je grootse plannen, dan zal je op lange termijn echter rekening moeten houden met een transitie naar modernere oplossingen.

Niet alleen voor je performance problemen

Tot nu toe heb ik ‘headless WooCommerce’ oplossingen alleen geïmplementeerd in gevallen van grote performance issues met een WooCommerce webwinkel. Maar een ‘headless platform’ biedt meer dan een oplossing voor je performance problemen. De Gartner group -een niet onbetekenende organisatie met betrekking tot de toekomst van e-commerce- heeft voorspeld, dat voor de nabije toekomst (de Gartner group noemt 2023) API based e-commerce platforms met een ‘Omni channel’ aanpak een duidelijke voorsprong zullen hebben op ondernemers die gebruik maken van ’traditionele’ e-commerce.

Een alternatieve term voor ‘headless e-Commerce’ is ‘Composable (e-)commerce’. Ofwel een (e-)commerce aanbod wat je zelf op basis van benodigde diensten samen kan stellen.

Maar dat kan ik toch al met WooCommerce plugins en extensions?

Ik hoor je nu al denken : ‘Maar dat kan ik toch al met WooCommerce, WooCommerce heeft plugins en extensions voor vrijwel iedere toepassing’?

Ik moet je hierbij teleurstellen. Dat is dus duidelijk niet zo. Door de monolitische aanpak van WordPress (en daarmee ook WooCommerce) is het wel mogelijk een aantal diensten in je website ‘in te schuiven’ door middel van plugins, maar je hebt weinig tot geen controle over de presentatie. En het wordt nog veel problematischer, wanneer we realiseren, dat wanneer we mobiel willen gaan, veel WooCommerce plugins die je nu misschien gebruikt ineens hopeloos zullen falen.

Om met een mobiele app te kunnen communiceren gebruiken we namelijk een protocol als ‘WP REST’ of ‘GraphQL’. WP REST is ‘ingebouwd’, en GraphQL kan middels een plugin op je site worden geactiveerd.

Het probleem met veel WordPress en WooCommerce plugins is echter, dat de maker van de plugin zich uitsluitend heeft gefocust op de presentatie direct op het beeldscherm, niet bij de informatie uitwisseling via het WP REST, en al helemaal niet via het GraphQL protocol.

Hier liep ik zelf keihard tegenaan bij de ontwikkeling van een mobiele app voor één van mijn eigen shops

In de winkel wordt, afhankelijk van je locatie, de prijs in euro’s of dollars gegeven. De plugin die echter de prijs in meerdere valuta laat zien geeft geen informatie door via WP REST. Met als gevolg, dat in de REST interface verkeerde prijzen worden getoond.

En zo kan ik een lange lijst met plugins geven, die het ontwikkelen van een mobiele app voor jouw webshop toch best problematisch kunnen maken.

Natuurlijk, al deze problemen zijn op te lossen, maar de ‘oplossing’ is het ontwikkelen en installeren van een aantal maatwerk plugins om de plugins in jouw plugins op te lossen. Dat wordt uiteindelijk een behoorlijk prijzige en onderhoudsintensieve aanpak, waar niemand op zit te wachten.

Als WooCommerce niet voldoen, kunnen we dan beter niet helemaal met dit platform stoppen?

Ook dit is een heel terechte vraag. Persoonlijk peins ik er echter niet over om met WooCommerce te stoppen. Niet voor mijn eigen shops en niet om als product aan te bieden aan startende webwinkeliers. Ik ben sinds 2002 actief op het gebied van e-commerce. Ik heb webshops gebouwd toen ‘online betalen’ zelfs nog helemaal niet mogelijk was zonder creditcard.

Het bouwen van een manier om online producten te presenteren is eigenlijk helemaal zo moeilijk niet. De complexiteit zit hem vooral in de backend. De ontwikkeling van een goede backend toepassing in een e-commerce applicatie is geen eenvoudige klus.

Dat is ook een reden, dat ik toen WooCommerce pas verscheen absoluut anti was. Die eerste versies van WooCommerce voldeden absoluut niet aan wat ik van een e-commerce applicatie verwachtte, of vond dat de klant mocht verwachten. In 2010, 2011 en begin 2012 was mijn ‘voorkeur oplossing’ voor een goede e-commerce oplossing een combinatie van WordPress en Magento.

Maar WooCommerce is gegroeid… Magento niet zoveel. En wanneer ik kijk bij de oplossingen voor ZZP-ers en het MKB, dan is WooCommerce op het gebied van ‘Wat kan je ermee’ toch één van de beste oplossingen. En eigenlijk is de populariteit van WooCommerce ook één van de grote oorzaken van de problemen ermee.

WooCommerce en de Haarlemmer Olie

Ik moet eerlijk zeggen, dat ik uit eigen ervaring geen flauw idee heb wat ‘Haarlemmer Olie’ nu precies is. Het was volgens mijn vader echter een ‘schijnoplossing voor alle problemen’. De generatie van zijn ouders zagen in Haarlemmer Olie de oplossing voor veel problemen.

Het grote succes van WooCommerce is ook direct de tragiek van het feit, dat het in extreem veel situaties wordt toegepast.

WordPress is nooit gebouwd als een ‘e-commerce systeem’. En WordPress heeft zelf dus absoluut geen ‘betaalmodule’ ingebouwd.

Wanneer je dus op de één of andere manier via WordPress wilt betalen, dan moet een plugin voor een eigen betaalsysteem ontwikkelen. Helaas zijn er enkele honderden betalingsmethoden en nog veel meer betalingsproviders wereldwijd. Dat kan je als simpele plugin ontwikkelaar niet meer bijhouden, dus de ‘WordPress standaard’ voor plugins met betaalmogelijkheden is geworden, dat je Stripe en PayPal ondersteunt, en voor alle andere betaalmethoden een uitstapje naar WooCommerce maakt. Want in WooCommerce is er voor vrijwel iedere betaalprovider een plugin beschikbaar. Prachtig.

Maar stel. Jij hebt een online leeromgeving en bovendien organiseer je ‘gewone’ cursussen, waar mensen zich online op in kunnen schrijven. Voor die gewone cursussen heb je een evenementen plugin met betaalmogelijkheden. Omdat beide plugins alleen PayPal en Stripe accepteren als ‘ingebouwd, en voor de rest naar WooCommerce doorverwijzen heb je -ondanks dat je geen webwinkel hebt- ook WooCommerce geïnstalleerd.

Je hebt nu dus drie plugins met betaalmogelijkheden. Van twee gebruik je deze mogelijkheden niet, maar ze worden wel ‘meegeladen’ met de plugin.

En dat is nog maar het topje van de ijsberg. In een eeuwigdurende concurrentiestrijd om een plugin toch maar zo ‘volledig mogelijk’ te maken, heb je waarschijnlijk een aardig aantal plugins geïnstalleerd staan met overlappende mogelijkheden. En dat zal in de toekomst alleen nog maar erger worden.

Tijd voor het ‘detoxen’ van je webshop

Onlangs las ik een artikel waar terloops even gesteld werd, dat bij een gemiddelde (niet gecachte) WordPress website 60% van de laadtijd verloren gaat aan plugins voor de ‘interne administratie’ van WordPress. Plugins als backup plugins, security plugins, ‘broken Link checkers’, statistische plugins, SEO plugins en -hoe ironisch- caching plugins.

Volgens mij is dit behoorlijk overdreven, maar wat wel waar is, is dat ik een tijdje terug met een klant naar de performance van zijn site heb gekeken en daarbij ontdekten we dat 20% van de totale performance ‘op’ ging aan WordFence.

De plugin die ervoor zorgde, dat de ongewenste bezoekers wegbleven (b)leek ervoor te zorgen, dat de gewenste bezoekers weggingen.

Door deze plugin door een andere beveiligingsplugin te vervangen, werd zijn site al behoorlijk wat sneller.

Het aardige van een ‘headless WooCommerce’ is echter, dat je dit soort plugins helemaal niet nodig hebt.

Composable e-commerce en WooCommerce

Het idee van Composable e-Commerce is dat de verschillende diensten die je nodig hebt, als losse zelfstandige apps draaien.

En laten we gelijk maar duidelijk zijn, dit kan waarschijnlijk niet zomaar bij jou op dit moment favoriete hosting provider. De meeste van dit soort oplossingen zijn cloud gerelateerd.

Wanneer we even terug kijken naar ‘WooCommerce als betaalmechanisme voor een online leeromgeving’, dan merken we op, dat er eigenlijk veel functionaliteit in WooCommerce zit, die je absoluut niet nodig hebt. Zoals bijvoorbeeld een complete product catalogus. ‘e-Commerce’ is niet per se hetzelfde als winkelverkoop.

Ik heb ook één klant, die de afrekenfunctie van WooCommerce absoluut niet nodig heeft. Hij verkoopt gebruikte autos. Die product catalogus van WooCommerce is geweldig, maar hij heeft geen ‘orders’, hij rekent niet online af… mensen komen gewoon langs, betalen en nemen de auto mee.

Het proces van een webshop is op te splitsen in minimaal een 5 tal services,

• Het tonen van je productaanbod (de catalogus)
• Het bestellen en betalen (checkout / ordering systeem)
• Facturering / financiële verslaglegging
• Het toegangsbeheer voor je klanten (zodat ze in kunnen loggen en hun gegevens bijhouden)
• Je klantbeheer (zodat jij weet aan wie je hebt verkocht en ze eventueel kan mailen)

Het idee van ‘Composable e-Commerce’ is, dat je niet zomaar iedere service die ‘hoort’ bij het pakket gebruikt, maar dat je met elkaar communicerende diensten gebruikt, die onafhankelijk van elkaar functioneren.

En met name dat ‘onafhankelijk van elkaar functioneren’ is een belangrijke factor.

Laten we nu eens kijken hoe we WooCommerce kunnen ‘decomposen’ om er een ‘composable e-Commerce service’ van te maken.

Headless WooCommerce als ‘Management App’

Zoals al aangegeven, de gegevensstructuur van WooCommerce zit heel goed in elkaar. Wanneer je serieus begint na te denken over ‘headless e-commerce’, dan is ‘headless WooCommerce’ toch de eerste optie om te overwegen, niet alleen, omdat je daar jouw klanten- en productenbestand al in hebt staan.

Vanuit een ‘NextJS’ website is het zondermeer mogelijk om via de WooCommerce API direct met WooCommerce te communiceren.

Op het moment dat WooCommerce niet langer verantwoordelijk is voor het tonen van je producten, kan je waarschijnlijk een groot aantal plugins deactiveren. Sterker nog, je kan zelfs je thema vervangen door een supereenvoudig thema wat alleen maar uit een leeg bestand ‘index.php’ bestaat. Jouw WooCommerce website zal nooit meer wat laten zien, maar dat is ook de bedoeling niet. Dat gebeurt op een andere plaats. Jouw nieuwe NextJS website.

Een NextJS website die ‘spreekt’ met een afgeslankte WooCommerce website zal al een enorme snelheidswinst betekenen. Je kan echter nog een stap verder gaan.

Een Catalogus Service

De WordPress ‘Post’ met custom posts (nieuw in WordPress 3.0, 17 juni 2010) was één van de belangrijkste redenen voor de plotselinge doorbraak van WordPress als CMS. Het idee was even eenvoudig als geniaal. Het betekende onder meer, dat het mogelijk werd om zonder te programmeren compleet nieuwe ‘gegevensstructuren’ in WordPress te definiëren. En het betekende ook, dat die gegevensstructuren er voor de WordPress gebruiker wel heel bekend uit kwam te zien. Want of je nu een product, een evenement of een blogpost invoert, het ziet er allemaal aardig hetzelfde uit.

Dit komt, omdat eigenlijk heel veel informatie in WordPress is vastgelegd in slechts twee tabellen : wp_posts en wp_postmeta.

De tabel wp_post bevat de ‘basisinformatie’ over een post. De tabel ‘wp_postmeta’ is eigenlijk een enorme tabel met slechts drie gegevens : Het ID van de post waar het bij hoort, de naam van het veld en een waarde voor het veld.

Op deze manier kan je zo’n ‘custom post type’ met eigenlijk een oneindig aantal velden uitbreiden. Het nadeel is echter, dat er vaak ook een ‘oneindig aantal velden’ mee geassocieerd is. Want veel plugins voegen zo hun velden toe aan WordPress en wanneer je die plugin verwijdert, blijven die velden vaak staan. Niet iedere programmeur zorgt voor een ‘grote schoonmaak’ na het deïnstalleren van zo’n plugin.

Toen ik enkele maanden terug eens tijd stak in het ‘opschonen’ van mijn wp_postmeta tabel, kon ik meer dan 60% van de gegevens verwijderen.

Maar WP REST kan dat onderscheid niet zien en zal alle velden, nodig of niet, meegeven. Beter mee verlegen, dan om verlegen. Het is echter niet ondenkbaar, dat deze velden privacy- of veiligheidgevoelige informatie bevatten!

Een bijkomend probleem wordt gevormd door variabele producten. Opnieuw, het is een briljant idee! Maar een variabel product wordt in WooCommerce opgebouwd door één ‘parent’ product te hebben. In zo’n ‘wp_postmeta’ veld staat aangegeven, dat het producttype ‘variant’ is, en daardoor weet WooCommerce, dat er andere posts/producten zijn die in hun ‘parent ID’ verwijzen naar deze ‘variant parent’.

Stel nu eens voor, je hebt een t-shirt in 5 maten en 8 kleuren. Dat zijn dus 40 varianten. Vraagt jouw nieuwe ‘NextJS site’ dan komen er via die ‘WP REST’ interface maar liefst 41 shirts de kant van de website op. En omdat al die informatie in twee tabellen staat, moet er ook even gegoocheld worden met de informatie.

Het gesprek tussen WooCommerce en de database gaat ongeveer als volgt.

WOO : Geef mij product 123
DB : Dat is een variabel product.
WOO : Ok, geef mij ook alle producten die product 123 als ‘parent’ hebben.
DB : Ok, dat zijn 124, 125, 126, […,] en tenslotte 164.
WOO : Dank je. Geef me ook alle ‘metadata’ van 124…
DB: Alsjeblieft…
WOO: En graag ook die van 125…
DB: Nogmaals, alsjeblieft…
[en een tijdje later]
WOO: En tenslotte van 164
DB : Alsjeblieft, anders nog iets?
WOO: Nee dank je…. (tegen de REST API), Hey REST interface, hier heb je de gegevens voor product 123, houd je vast, het is een hoop!

Wil je ook nog eens een keer een x-aantal producten op een homepage of product pagina kunnen laten zien, met ‘van’- ’tot’ prijzen ingeval van variabele producten, dan snap je al, dat dit behoorlijk wat verkeer tussen WooCommerce en Database en WooCommerce en REST API is.

Dat kan een stuk efficienter.

Zelf werk ik daarom het liefst met een zogenaamde ‘Catalogus Service’. Die ‘Catalogus Service’ is een (lichtgewicht) JavaScript toepassing op een cloud server, die contact opneemt met WooCommerce en alle producten inleest.

In plaats van deze gegevens echter in twee tabellen in een SQL database op te slaan, worden deze opgeslagen in een zogenaamde ‘NoSQL’ database. Dat is een database waarin gerelateerde informatie allemaal ‘bij elkaar’ wordt opgeslagen. Dat zorgt er onder meer voor, dat het opvragen van een variabel product in één keer kan.

Bovendien ‘spreekt’ deze Service dezelfde ’taal’ als de NextJS frontend voor je webshop, waardoor de informatie snel verwerkt kan worden.

Verander je een product in WooCommerce? Dan wordt via een ‘webhook’ de ‘Catalogus Service’ hiervan op de hoogte gesteld. WooCommerce ‘port’ de service, dat er wat te doen is, en vervolgens zal de service de gegevens alleen voor dat product opvragen en bewerken. Zo blijft de catalogus altijd ‘in sync’ met WooCommerce.

Deze oplossing heeft een aantal grote voordelen :

• Binnen WooCommerce is het opvragen van producten de meest ’tijd consumerende’ taak. Door deze catalogus in een ’tussenservice’ op te slaan,
• Omdat de Service gebruik maakt van een meer moderne technologie en daardoor ‘lichtgewicht’ en sneller is, maar ook omdat de gegevens ‘klaar voor gebruik’ worden opgeslagen, verloopt de communicatie tussen de frontend en de service vlotter.
• Omdat WooCommerce ‘de handen vrij heeft gekregen’, kan WooCommerce aan de slag, met die zaken die exclusief aan WooCommerce zijn voorbehouden, namelijk gebruikersauthenticatie en het afhandelen van orders. Ook dit gebeurt alleen ‘op de achtergrond’.

De ‘bestel’ service…

Bij het plaatsen van bestellingen zijn allerlei belangrijke regels rond korting, bijkomende kosten (verzending), belasting en andere zaken van groot belang. Dat is een belangrijke reden, waarom voor bestellingen ‘direct’ contact gelegd zal worden met de ‘order’ module van WooCommerce.

Direct staat bewust tussen aanhalingstekens, omdat in verband met security vanuit de front end site uitsluitend contact met WooCommerce gemaakt zal worden via een proxy, die overigens opdrachten één op één (maar wel gecontroleerd) doorstuurt.

De betaalservice

Omdat voor een goede werking van online betalingen een userinterface van groot belang is, en eigenlijk geen enkele betaal plugin goed samenwerkt met de WP REST interface, heeft WordXPression een aparte ‘betaalservice’ voor headless WooCommerce moeten ontwikkelen. In de huidige versie wordt er per shop maar één betaalprovider ondersteund. Een betaalprovider kan overigens meerdere betaalmethoden hebben.

Op dit moment zijn er betaalservices voor Mollie of Stripe. Beiden ondersteunen de in Europa belangrijkste betaalmethoden:

• iDEAL
• Bancontact
• Sofort
• Creditcard
• PayPal

Daarnaast hebben beide providers nog een aantal andere betaalmethoden, die specifiek zijn voor die provider, specifiek zijn. Controleer dus zelf even, of een door jou specifieke niet gewenste betaalmethode door de provider ondersteund wordt.

Het bestelproces

Zolang een bezoeker niet is ingelogd zal voor die bezoeker -net zoals in WooCommerce- bij de frontend applicatie in een cookie de winkelwagen worden bijgehouden. Zodra een bezoeker inlogt, wordt de inhoudt van de winkelwagen opgeslagen in de database.

Zodra een bestelling wordt doorgegeven, wordt deze opgeslagen in WooCommerce. De gebruikte betaalmethode is ‘JAM Service’, die verwijst naar de betaalservice waarmee de website communiceert. De service handelt de betaling af en zodra dit ‘ok’ is, wordt de order op ‘betaald’ gezet. Eigenlijk niet anders dan voorheen, behalve dat de betaalservice een andere naam krijgt.

Kortom, voor jou, werkend in de backend van WooCommerce verandert er niet zoveel. Voor de gebruikerservaring (razendsnelle website!) wel.

Bonus : Multi Store is een standaard mogelijkheid!

Wanneer je kijkt naar mijn artikel over Multi Store oplossingen, dan biedt een headless WooCommerce je dit eigenlijk standaard al aan. Zonder enige extra plugins!

Even een reminder. Wat was ook al weer ‘Multi Store’… het idee achter een Multi Store oplossing is dat je meerdere webshops hebt, die allemaal bevoorraad worden vanuit eenzelfde magazijn. Je hebt dus diverse shops, maar je wilt je producten centraal invoeren, de bestellingen vanuit één interface kunnen behandelen en je overzichten ook met de spreekwoordelijke één druk op de knop kunnen oproepen.

Daar heb je echter een plugin voor nodig. En helaas is de WooMultiStore plugin niet alleen de enige in zijn soort, maar ook nog eens behoorlijk aan de prijs.

Bovendien is het ‘runnen’ van 20-30 winkeltjes met deze plugin echt geen goed idee, omdat het toch allemaal op die ene (monolitische) WordPress installatie aan zal komen.

Met een headless WooCommerce heb je deze zorgen niet meer. Wanneer je de producteigenschappen gebruikt om je onthoofde WooCommerce te vertellen in welke winkels jouw product moet zijn opgenomen, dan wordt in de bovengenoemde oplossing met een aparte ‘catalogus service’ jouw probleem eigenlijk vanzelf afgehandeld.

De producten worden op basis van de opgegeven ‘producteigenschappen’ groep (die je bijvoorbeeld ‘Storefront’ noemt) gekoppeld aan de juiste catalogus service. Per ‘verkooppunt’ heb je dus een eigen catalogus service, maar zodra je klant overgaat tot bestelling, komt deze uiteindelijk toch in één en dezelfde WooCommerce.

Voor meer informatie, ben je altijd welkom contact op te nemen.

En wat gaat zo’n headless WooCommerce mij kosten?

Zo’n verhaal over ‘headless WooCommerce’ is natuurlijk wel leuk, maar waar het allemaal uiteindelijk om gaat zijn de kosten. En ik zal er niet omheen draaien. Een ‘headless WooCommerce’ installatie kost aardig wat meer -om verschillende redenen- dan een ‘gewone’ WooCommerce

Met een ‘gewone’ WooCommerce site kan je prima een gratis- of betaald thema downloaden en installeren in je WordPress site. Voeg WooCommerce toe en hoera! Voor vrijwel geen kosten anders dan je hosting kosten heb jij je website online. Gefeliciteerd.

Een andere mogelijkheid -wanneer je het wat professioneler aan wilt pakken- is dat je jouw site laat bouwen door webbouwer met alweer 20 jaar ervaring op het gebied van e-commerce. Dan ben je -afhankelijk van je wensen- 1200 euro of meer kwijt, maar je hebt een volledig werkend e-Commerce systeem.

Een ‘headless WooCommerce’ gaat je meer kosten. Reken er op, dat je alleen voor de NextJS website zo’n 1200-2000 euro kwijt bent. De ‘catalogus’ en de ‘betaalservice’ gaan je ook geld kosten.

Mijn persoonlijke advies is om deze diensten onder te brengen op Amazon AWS. Op termijn is dit de voordeligste oplossing. In de nabije toekomst volgt er nog een artikel over het ‘waarom’, maar als je nu al serieuze interesse hebt, leg ik het je graag persoonlijk uit.

Amazon AWS is een dienst waar je niet per maand betaald, maar betaald voor het werkelijk gebruik. De kosten die je hier maakt zijn dus sterk afhankelijk van de populariteit van je site!

En tenzij je zelf een expert op het gebied van AWS bent, zal je hier iemand voor moeten betalen. Nu heb je geluk, dat ik zelf al heel wat jaartjes ervaring met Amazon AWS hebt, en vanaf 30 euro per maand jouw ‘cloud’ daar (we kunnen niet langer meer van een site spreken) kan onderhouden.

Het mag duidelijk zijn. Een ‘headless WooCommerce’ is niet bedoeld als oplossing voor een startende ondernemer, tenzij deze vanaf de start al grootse aspiraties heeft.

Ben je een ‘doorsnee ZZP-er’, die zijn shop online wil krijgen, dan is ‘Old School’ WooCommerce een prima, zo niet de beste, start. Maar denk je in duizenden bezoekers per dag, of maken op dit moment jouw duizenden bezoekers per dag jouw website toch wel tergend traag… Maak even een belafspraak en we kijken hoe we dit voor jou op kunnen lossen.