WooCommerce – The Next Generation

Op het moment dat ik dit artikel schrijf, is WooCommerce één van de meeste gebruikte e-Commerce programma wereldwijd. Wanneer je al langer mijn blog leest, dan trek je nu wellicht even een wenkbrauw op. Eén van de meest gebruikte? Was WooCommerce niet altijd het meest gebruikte?

Wat is er ondertussen veranderd?

Om die vraag te beantwoorden, moeten we even kijken hoe we het ‘gebruik’ van e-commerce software nu eigenlijk willen meten. Maar voor we dit doen, laten we eerst eens een blik op de cijfertjes werpen. Ik gebruik hiervoor twee bronnen.

BuiltWith en Statista. Drie op zich betrouwbare bronnen met totaal verschillende cijfers. Nou ja… totaal.

BuiltWith

Built kijkt naar de top miljoen websites op het Internet en bepaalt dan wat voor websites het zijn.

Van die miljoen websites zijn 298,228 websites e-commerce websites. En de top drie van deze websites worden gevormd door

Statista

Statista kijkt naar alle websites op het Internet. Dat betekent, dat ook al die websites die niet in de ’top miljoen’ staan ook in de berekeningen worden meegenomen. En dan krijg je natuurlijk totaal andere getallen.

100 Sklepow

Nu had ik zelf nog nooit van 100 Sklepow (Pools voor ‘100 winkels’) gehoord, dus het leek mij wel aardig om daar iets meer over te weten te komen. Wel, het product bestaat niet meer en de domeinnaam van de website staat op het moment dat ik dit schrijf te koop. Wat meer gegoogel maakte duidelijk dat dit bedrijf al enige tijd geleden is opgehouden met bestaan. Maar de software wordt nog steeds gebruikt klaarblijkelijk, ook al vind je deze sites niet terug in de top-1-miljoen van websites!

WooCommerce leidt nog steeds de markt

Absoluut gezien is WooCommerce dus niet langer de ‘marktleider’, maar wanneer je kijkt naar succesvolle websites, dan is WooCommerce nog steeds de absolute marktleider.

Ook interessant om op te merken, dat SquareSpace, die op dit moment met een neuslengte voorsprong WooCommerce heeft ingehaald, binnen de ’top miljoen’ slechts goed is voor 0,25% van het totaal.

Maar WooCommerce staat dus in de serieuze markt nog steeds eenzaam aan top. Het lijkt dus goed te gaan met WooCommerce. Waarom zou het dan nodig zijn om aan ‘WooCommerce The Next Generation’ te denken?

WooCommerce is zwaar

Het grote probleem van WooCommerce is dat het eigenlijk topzwaar is. En dat heeft alles te maken met de manier waarop er 10-15 jaar geleden Internet software werd gebouwd. Alles ‘greep in elkaar’. En alhoewel het hele plugin systeem van WordPress werkelijk briljant in elkaar zit, zorgt iedere plugin voor een vertraging van je systeem.

Linux, Apache, MySQL en PHP hebben producten als WordPress mogelijk gemaakt, maar nu zitten ze eigenlijk de groei van WordPress in de weg.

Monolithen en het stenen tijdperk

Hierboven zie je in kaart gebracht hoe WooCommerce ongeveer werkt. Wanneer je een willekeurige pagina opvraagt, dan geef je jouw verzoek door aan de webserver. Die webserver komt er na enig intelligent gegoochel achter, dat je eigenlijk wilt, dat jouw verzoek wordt afgewerkt door PHP. Het verzoek wordt doorgegeven en PHP ontdekt, dat om het verzoek af te kunnen handelen, er gegevens uit de database nodig zijn, want alle content, of het nu gaat over het beheer, de presentatie, het betaalproces, je product catalogus of de systeem instellingen, is daar opgeslagen.

Wanneer jij -of je bezoeker- om een enkele pagina vraagt, dat is het niet uitzonderlijk, dat er letterlijk honderden vragen aan de database worden gesteld.

Deze manier van ‘werken’ wordt, omdat je een opeenstapeling van Linux (Operating system van de meeste webservers), Apache (de webserver software), MySQL (de database) en PHP (de ‘vertaler’ van programma tekst naar machine instructies) nodig hebt om dit uit te voeren, een LAMP stack genoemd.

De JAMStack

Een modernere technologie die in 2015 serieus genomen begon te worden en nu inmiddels aan het uitgroeien is tot een nieuwe standaard is de zogenaamde ‘JAMStack’. En JAM heeft hier niets te maken met broodbeleg of gezellig een muzikaal feestje bouwen, maar JAM staat hier voor JavaScript, API’s and Markup.

En de aanpak hier is totaal anders. Want niet langer wordt er meer vertrouwd op één systeem wat alles regelt, maar op een website die communiceert met verschillende ‘API’s’, met verschillende ‘Application Program Interfaces’).

Aan de kant van de bezoeker staat een statische website met HTML (de ‘markup’), JavaScript en CSS. Ergens op het Internet staan er diensten die op de website gebruikt moeten worden. En het is zaak, dat die communicatie zo vlot mogelijk verloopt. Laten we eens kijken naar een paar essentiële verschillen.

De front-end

Wanneer we ‘Jamstacks’ praten, dan hebben we het over een front end als de toepassing die de bezoeker gebruikt. Dat kan een website zijn. Maar het kan even goed een smartphone zijn, of een POS systeem of bijvoorbeeld een geldautomaat. In het kader van mijn voorbeelden beperk ik mij echter tot websites en mobiele apps.

Alle informatie die de frontend nodig heeft om ‘front end te zijn’ is al bekend bij de front-end. Er zal dus geen contact gezocht worden met een database om ‘paginagegevens’ op te halen. Alle nodige statische informatie voor het presenteren van de site is aanwezig.

De back-end

De back-end. Tja, dat is eigenlijk een verhaal apart. Hoewel het heel goed mogelijk is om één backend te bouwen, is dat eigenlijk heel ‘on-Jamstacks’. Want dat zorgt er weer voor, dat je afhankelijk wordt van één enkel onderdeel en ben je bijna weer terug bij ‘af’ met een monolithische toepassing.

Een Jamstack front-end spreekt bij voorkeur niet met een server, maar met services. En dat is meer dan alleen een semantisch spelletje. Het is een wezenlijk verschil. Het grote verschil is namelijk, dat de front-end helemaal geen kennis hoeft te hebben van hoe dingen precies in de back-end verwezenlijkt worden. Het enige wat van belang is, is die API, die ‘applicatie program interface’ waarmee gesproken moet worden.

Laten we eens een bekend voorbeeld nemen. MailChimp. Wanneer je via de API met MailChimp praat, dan stuur je berichten naar MailChimp als

GET /lists/

Vervolgens zal MailChimp je een tekstbericht toesturen met alle lijsten die jij hebt in MailChimp. Laten we zeggen, dat je speciaal geïnteresseerd bent in lijst 123. Het volgende wat je bijvoorbeeld kan zeggen is

GET /lists/123/members

En je raadt het all, je krijgt nu alle leden van die lijst.

Wat je absoluut niet hoeft te weten is hoe intern in MailChimp nu al die zaken zijn opgeslagen.

Stel je voor (ik heb er geen flauw idee van wat ze gebruiken), dat MailChimp alle gegevens opslaat in een MySQL database. En ze besluiten om wat voor reden dan ook, om morgen over te stappen naar MongoDB, een database die volgens een compleet ander principe werkt. Intern zullen ze even een flinke klus hebben, maar richting de buitenwereld toe hoeft er aan die API niets te veranderen.

Meerdere services

Maar ok, het is nu wel duidelijk dat een directe koppeling met een database zoals in WordPress/WooCommerce destijds wel de enige mogelijkheid leek, maar het is niet de beste. Maar kan een applicatie niet gewoon met slechts één server praten? Waarom moeten dat verschillende services zijn?

Stel je nu eens voor. Je hebt een webshop. Dat voorstellen is waarschijnlijk vrij makkelijk, omdat ik me uitsluitend kan bedenken, dat mensen met een webshop, of met plannen met een webshop te beginnen, dit artikel lezen. En jouw API Service biedt alles wat je wilt in één grote applicatie. En jouw website praat via de API met die service. Da’s dus eigenlijk gewoon de WordPress/WooCommerce situatie met enkele verbeteringen. Wat is daar mis aan?

Niet veel, zolang alles probleemloos blijft draaien, maar wat nu als je een storing hebt? In één keer ligt alles eruit. Laten we eens naar een webshop kijken. Wat voor ‘services’ zijn daar zoal in de onderscheiden.

• De catalogus
• Het bestelsysteem
• Gebruikers-/klantenbeheer
• Het logistieke systeem
• Het marketing / management informatie systeem

Er bestaat een zekere afhankelijkheid tussen de systemen, maar hoe onplezierig ook, wanneer er bijvoorbeeld een storing in het bestelsysteem zou zijn, is het toch wel fijn, wanneer de site gewoon ‘up and running’ is, met eventueel een melding ‘door onderhoud aan ons bestelsysteem, kunt u op dit moment geen orders plaatsen, bedankt voor uw begrip‘. Mensen kunnen nog steeds door de winkel gaan en hun winkelmandje vullen. Klinkt toch stukken beter dan ‘503 Internal Server Error’, nietwaar?

Separation of concerns

Met een duur woord wordt dat ‘Separation of Concerns’ genoemd. Uit dat hele netwerk van services kan je ‘zomaar’ een service vervangen. Zelfs zonder dat het echt merkbaar hoeft te zijn voor de gebruiker. Stel je voor, dat je op een gegeven moment besluit om -heel wild- een compleet andere service voor je catalogus beheer te gaan gebruiken. Zolang de ‘API’ maar dezelfde ‘opdrachten’ accepteert, kan je dat zonder meer doen. Zelfs -indien er in ieder geval dezelfde producten in voorkomen- zonder dat de bezoekers hier iets van hoeven te merken.

Nogmaals ‘WooCommerce the Next Generation’

Je zal je wellicht nog steeds afvragen wat dit nu met jouw WooCommerce shop te maken heeft. Misschien niet zo gek veel, misschien ook alles. Dat ligt een beetje aan je situatie.

Wanneer een grote, goedlopende webshop hebt en je vandaag de dag serieuze performance problemen hebt met WooCommerce, dan moet je beslist verder lezen. Wanneer je net gestart bent met je webshop en eigenlijk op wat meer bezoekers zit te wachten… dan kan je ook verder lezen, om te zien wat je mogelijkheden in de toekomst zijn, maar voorlopig is dit niet op jou van toepassing.

Een tijdje terug heb ik geschreven over een ‘headless WordPress‘ En in dit blogartikel wil ik samen met jou verder kijken naar een ‘headless WooCommerce’. We kunnen namelijk WooCommerce ook benaderen via de zogenaamde ‘REST API’ of -na het installeren van een tweetal plugins- via de GraphQL API. Twee manieren die ook gebruikt kunnen worden met de front-ends die ik verderop bespreek.

De Fransen hebben het eind 18e eeuw al bewezen. Wil je een revolutionaire verandering, dan kan onthoofden een optie zijn.

SPA’s

Zo rond 2014, 2015 kwam de term ‘Single Page Applications’ erg in zwang. Een ‘Single Page Application’ is een pagina die zich ‘gedraagt’ als een complete applicatie. Voor die tijd bestonden die ook wel (GMail is er bijvoorbeeld een mooi voorbeeld van), maar met de opkomst Node.JS (Node.JS is in 2009 ‘ontstaan’, maar pas in 2015 -met het oprichten van de Node.js foundation- kreeg het platform de stabiliteit die nodig is om het een populair platform te maken) kwam het werkelijk van de grond.

Een ‘Single page application’ is een programma wat ‘runt’ in je webbrowser en HTML, JavaScript en CSS nodig heeft. En grote programma’s schrijven met behulp van JavaScript is een crime. Dat wil je niet. In ieder geval niet zonder een goed framework.

En rond dat hele Node.JS platform is er een drietal goede frameworks voor JavaScript SPA’s ontstaan.

Angular, Vue en React. En naar dat React platform wil ik graag wat verder met je kijken.

React

React komt uit de keuken van Facebook. Facebook had een manier nodig om snel interactieve webpagina’s te bouwen… die bovendien ook nog eens snel in de uitvoering zouden zijn. Jordan Walker bedacht een product, voor zijn werkgever, wat hij FaxJS noemde en de basis werd voor het latere React. In 2013 werd React door Facebook als open source software vrijgegeven.

Wat nu allemaal de voordelen van React zijn, zijn hoofdzakelijk de voordelen voor de webbouwer/programmeur zelf (React is meer programmeren, dan webdesign). Voor de eindklant zijn er slechts drie voordelen : Veilige, snelle sites die relatief voordelig gebouwd kunnen worden.

Nu is React helemaal geweldig voor sommige zaken, maar iedere SPA, of het nu in Angular, Vue of React gebouwd is, is compleet onzichtbaar voor Google. Een SPA is dus geweldig op pagina’s die alleen zichtbaar zijn, wanneer een gebruiker is ingelogd, maar je wilt het absoluut niet gebruiken voor een complete website. Tenzij je natuurlijk graag onzichtbaar blijft voor de search engines.

Gatsby

Gatsby is framework voor het bouwen van hybride sites met behulp van React. Maar wat is nu in vredesnaam een ‘hybride site’.

In meer dan één blogpost heb ik je verteld, hoe het ‘bouwen van de pagina door de server’ iedere keer weer je website aanzienlijk vertraagt. En een behoorlijk snelle pagina die de informatie ophaalt uit ‘Services’ ervoor zorgt dat je pagina compleet onzichtbaar is voor de buitenwereld.

En laat Gatsby nu eigenlijk het ‘best of both worlds’ bieden.

Stel nu, je hebt een product pagina. Aan die product pagina zal niet veel ‘spontaan’ veranderen, behalve misschien de voorraad. En die voorraad is toch wel een heel belangrijk gegeven.

Wat je nu typisch met Gatsby kan doen is de product pagina als ‘hybride’ pagina te gebruiken. Alle productpagina’s worden dus éénmalig als statische pagina gegenereerd, maar als een pagina geladen wordt, vraagt deze de voorraad op via JavaScript. Je krijgt dus altijd de meest recente voorraad te zien. Deze techniek wordt ‘hydrating’ genoemd.

Maar wat nu wanneer je bijvoorbeeld de omschrijving van een artikel aanpast?

Wanneer je belangrijke informatie (zoals prijzen en product beschrijvingen) aanpast, dan zal je een nieuwe ‘build’ van de site uit moeten voeren, de pagina’s worden opnieuw aangemaakt.

De voordelen van Gatsby

Met Gatsby maak je een razendsnelle interface met een ‘headless eCommerce platform’. Bovendien kan je de statische pagina’s makkelijk in een content delivery network plaatsen, waardoor deze snelheid alleen maar beter zal worden.

Door het ‘hydrateren’ van wisselende gegevens als bijvoorbeeld de voorraad of de ster-waarderingen blijft er toch enige dynamiek in de site.

De nadelen van Gatsby

Bij veranderingen aan het product bestand worden deze pas zichtbaar na een nieuwe ‘build’ te hebben gemaakt. dit hoeft op zich geen probleem te zijn, maar heb je een groot productaanbod (denk aan duizenden producten), dan kan het letterlijk uren duren voor alles weer ‘bij’ is.

(React) NextJS

React NextJS is, zoals met het zelf op de site graag noemt, een React Platform For Production’. Het feit dat bedrijven als Facebook, NetFlix, Discord en Dropbox React gebruiken geeft je wellicht al een indicatie dat React (zonder ‘Next’) ook al een ‘platform for production’ was, maar NextJS voegt daar nog een dimensie aan toe. Of eigenlijk een ‘extra aantal dimensies.

De bedenkers van React NextJS hebben zo’n beetje alle probleemsituaties bekeken en getracht daar een oplossing voor te vinden. En daar zijn ze behoorlijk in geslaagd. Alles is bedoeld als ‘de right page at the right time’. En zonder te diep op de verschillende situaties in te willen gaan, noem ik graag de verschillende mogelijkheden:

• De pagina wordt ’tijdens de build’ door de server gegenereerd, daarna blijft hij statisch.
  Dat kan handig zijn voor bijvoorbeeld algemene voorwaarden pagina’s of andere pagina’s die nauwelijks veranderen.
• De pagina wordt altijd door de server gegenereerd.
  Dat kan handig zijn voor een besteloverzicht of andere pagina’s met dynamische vulling. In de meeste gevallen zal dit ook inhouden, dat de inhoud persoonsgerelateerd is, een SPA zou hier ook een goede optie zijn.
• De pagina wordt gegenereerd en na een x periode ‘invalidated’, oftewel ongeldig verklaard om opnieuw gegenereerd te worden.
• De pagina wordt altijd dynamisch geladen (als een SPA dus).

Geen caching

Nu is de op één na laatste situatie wel de meest interessante. Het lijkt dat we het hier gewoon over ‘caching’ hebben, maar niets is minder waar.

Wat gebeurd er namelijk met caching? Op het moment dat je een pagina opvraagt, wordt er gekeken of er nog een versie in de cache is, en zo niet, dan wordt deze opnieuw gegenereerd. Bezoek jij dus zo’n ‘invalidated’ pagina, dan moet je wat langer wachten dan normaal.

NextJS doet het net iets anders. Die zal jou de oude versie van de pagina laten zien, maar deze ‘bijwerken’ met de laatste gegevens die uit een backend service wordt opgehaald. Deze worden echter bijgewerkt volgens eenzelfde manier als de ‘hydrating’ van Gatsby.

Je krijgt dus eerst de statische pagina te zien met ‘oude’ informatie en direct daarna wordt de ‘verse’ informatie uit de API service opgehaald. De informatie in de pagina die inmiddels is veranderd wordt bijgewerkt, de rest niet.

In de meeste gevallen gaat dit zo snel, dat er niets van te merken is.

Nadat jij de pagina geleverd hebt gekregen, wordt deze aangemerkt om opnieuw gegenereerd te worden.

Het aardige van dat ‘opnieuw genereren’ is overigens, dat dat niet perse direct gebeurt. De prioriteit ligt namelijk bij het beantwoorden van verzoeken. Pas als het wat rustiger is, zullen de pagina’s die opnieuw samengesteld moeten worden, worden samengesteld.

Kortom, NextJS is letterlijk een ‘Next Generation’ web toepassing.

WooCommerce the Next Generation

En dan zijn we nu uitgekomen bij ‘WooCommerce the Next Generation’. Wellicht een wat lange aanloop, maar wanneer je een grote sprong wilt maken, is het altijd goed om met een aanloop te beginnen.

Want wanneer je serieuze performanceproblemen hebt met jouw WooCommerce website, dan kan je natuurlijk blijven investeren in optimalisatie en krachtigere hardware, maar je kan op een gegeven moment ook besluiten, dat het helemaal over een andere boeg gooit. En gelukkig kan dat met WooCommerce ook prima.

Wanneer je namelijk WooCommerce als ‘service’ gaat gebruiken, dan kan je jouw WooCommerce toch behoorlijk af laten slanken. Al die plugins voor weergave, veel plugins voor optimalisatie en beheer… het kan allemaal weg, tot je de ‘core’ van WooCommerce overhoudt. Een geweldig framework voor e-Commerce toepassingen.

Laat vervolgens deze ‘service’ benaderen door je nieuw te bouwen NextJS site… en je hebt een oplossing die het nog een hele tijd uit kan houden.

Binnenkort ga ik dieper in op een aantal manieren waarop je WooCommerce als ‘Headless e-Commerce’ service kan gebruiken.

Blijf bij

De WordXPression blog is niet ‘zomaar’ een WordPress blog, maar een blog met hart voor de toekomst. Wil je meer weten over ‘The Next Generation’ van WordPress, e-Commerce of e-Learning? Schrijf je dan in voor de nieuwsbrief of klik op de rode bel links om de WordPress browser push berichten te ontvangen.