Wat steekt er achter de schermen van deze maatwerk e-commerce site? Een diepgaande technische analyse

1. Ontvangen van de lege HTML-app-shell.
2. Downloaden van de JavaScript- en CSS-bestanden. Door de hashes in de bestandsnamen kunnen deze lang door de browser worden gecached.
3. React start op in de #root-div en de router leest het URL-pad om de juiste pagina-component te laden.
4. De pagina haalt de benodigde data op. Dit kan gebeuren via gebundelde data in window.__INITIAL_DATA__ variabelen, of door een REST API aan te roepen.
5. React bouwt de DOM op en koppelt event-handlers.
6. Bij interne navigatie wordt de URL via de History API gewijzigd, zonder de hele pagina te herladen. Alleen de component en de benodigde data worden vervangen.

Belangrijk punt: De aanwezigheid van window.__-variabelen is geen bewijs van Server-Side Rendering (SSR). Als de HTML alleen een lege root-div en wat JSON bevat, is dit slechts een 'bootstrap' voor client-side rendering (CSR). Echte SSR herken je doordat de productnaam, beschrijving, prijs en metadata al in de initiële HTML staan.

Het feit dat elke route dezelfde app-shell serveert, zorgt voor een snelle, SPA-achtige navigatie-ervaring na de eerste lading. Een groot risico is echter dat de server een HTTP 200-statuscode teruggeeft, zelfs voor niet-bestaande URL's (bijv. /product/niet-bestaand). De React-applicatie toont dan wel een 'niet gevonden'-melding, maar Google kan dit zien als een 'soft 404', wat de indexering schaadt. Volgens de richtlijnen van Google moeten dit soort fouten correct worden afgehandeld met een echte 404-statuscode of een noindex-tag .

1.3 De datastroom van de catalogus

De frontend bouwt de productcatalogus niet vast in de code, maar haalt deze op via de API. Dit is een groot voordeel, omdat prijzen, voorraad en afbeeldingen kunnen worden aangepast zonder de hele frontend opnieuw te hoeven bouwen.

De API-endpoints voor de catalogus zijn onder andere:

• GET /api/products?limit=500&active=1

  : Haalt alle actieve producten op.

• GET /api/products?q=...

  : Voor zoekopdrachten.

• GET /api/products/<slug>

  : Voor productdetails.

• GET /api/products/categories

  : Voor de categorietaxonomie.

De parameter limit=500 is een indicatie dat de API is geoptimaliseerd voor een kleinere catalogus. Voor de huidige 16 producten is dat prima, maar voor een catalogus met duizenden producten zou dit leiden tot grote payloads, trage queries en veel geheugengebruik in de browser. Een nieuwe backend zou beter gebruikmaken van cursor-pagination en aparte endpoints voor zoeken en filteren.

Het huidige productschema vertoont een aantal tekenen van een 'product-centric' in plaats van een 'variant-centric' benadering:

• De stock (voorraad) staat op productniveau, terwijl er ook variants bestaan.
• Velden zoals sizes, colors en genders staan zowel op het product als in de varianten, wat leidt tot inconsistenties.
• Er zijn inconsistenties in data, zoals zowel XXL als 2XL, en zowel

  ink navy

  als

  Ink Navy

  .
• De velden image en images lijken overlappende functies te hebben.
• Er bestaan generieke velden zoals type en isbn, die mogelijk zijn overgenomen uit een andere context.

Dit is een probleem omdat voorraad en SKU's (Stock Keeping Units) in werkelijkheid aan specifieke variantcombinaties zijn gekoppeld (bijv. Maat M in het Zwart). Een nieuwe implementatie moet opties normaliseren en voorraad en SKU's op variantniveau beheren.

1.4 De homepage-bouwer: een dynamische compositie

De aanwezigheid van section_order en aan/uit-schakelaars in de API-respons laat zien dat de homepage een dynamische compositie is die vanuit het CMS wordt aangestuurd. De frontend is niet in steen gebeiteld.

Een mogelijke werking:

1. De API (/api/homepage) retourneert een configuratie van alle secties.
2. De frontend doorloopt section_order.
3. Voor elke sectie (bijv. hero, trustbar, promo, products) wordt de bijbehorende React-component geladen.
4. Voordat een component wordt getoond, wordt de aan/uit-schakelaar gecontroleerd.
5. De component leest de bijbehorende gegevens, zoals afbeeldingen, tekst, links of productverwijzingen.

Voordelen: Het marketingteam kan de volgorde en zichtbaarheid van blokken wijzigen zonder een nieuwe frontend-release. De frontend is slechts een register van componenten; de data bepaalt de structuur.

Nadelen: Er zijn inconsistenties, zoals het naast elkaar bestaan van ann en announcement. Dit wijst op een verouderde alias of een niet-schone databasemigratie. Het grootste risico is dat de drie afzonderlijke structuren (section_order, de schakelaars en de payload) uit sync kunnen raken, wat leidt tot fouten.

Een nieuwe implementatie zou één enkele lijst van blokken moeten gebruiken, waarbij elk blok zijn eigen id, type, enabled-status, positie en payload heeft. Dit houdt alles bij elkaar en voorkomt synchronisatieproblemen.

1.5 Layout-bouwer en winkelinstellingen

Het lijkt erop dat /api/layout de configuratie voor de header, footer en navigatie bevat, terwijl /api/public/settings de merk- en winkelinstellingen (branding, policies) beheert. Het scheiden van de layout (die op elke pagina wordt gebruikt) van de homepage-compositie (die alleen voor de startpagina geldt) is logisch.

De lijst met instellingen wijst op een eenvoudige 'key-value' of JSON-configuratie die onder andere regelt:

• Merknamen en kleuren.
• Logo en favicon.
• Bedrijfsgegevens.
• Verzendkosten en drempelbedragen voor gratis verzending.
• Verwerkingstijden.
• Betalingsprovider (PayPal Client ID).
• Social media links, betaalmethoden, navigatie en aankondigingen.
• Campagne-instellingen (bijv. een 'outerwear sale').

Voordelen: Het is flexibel; nieuwe instellingen kunnen worden toegevoegd zonder een database-migratie.

Nadelen: Een pure key-value-aanpak mist typeveiligheid, verwijzingsintegriteit (foreign keys) en validatie. Zo kan standard_handling_min niet worden gecontroleerd of deze kleiner is dan standard_handling_max. Ook moeten URL's en booleans worden gevalideerd. Een nieuw systeem zou schema-validatie moeten gebruiken. Gevoelige informatie, zoals een belastingnummer (tax_id) of operationele e-mails, mag niet in de publieke API worden blootgesteld. De PayPal Client ID mag dan wel publiek zijn, maar het bijbehorende secret mag nooit in de browser of in window.__-variabelen verschijnen, omdat deze door gebruikers kunnen worden uitgelezen.

1.6 Coupons en PayPal-betalingen

Een waarschijnlijke betalingsstroom:

1. De browser stuurt de winkelwagen en couponcode naar de server.
2. De server haalt de actuele product- en variantgegevens uit de database en controleert de beschikbaarheid, voorraad en promoties.
3. De server berekent zelf het subtotaal, de korting, de verzendkosten, de belasting en het eindtotaal.
4. De server maakt een PayPal-order aan via /api/paypal/create-order met behulp van server-side credentials.
5. De browser opent de PayPal-goedkeuringsflow voor de klant.
6. Na goedkeuring wordt de betaling 'gecaptureerd' via /api/paypal/capture.
7. De server verifieert het bedrag, de valuta en de status, maakt de definitieve bestelling aan en past de voorraad aan.
8. Een PayPal-webhook dient als tegencheck voor asynchrone statuswijzigingen.

Essentieel: De server mag nooit vertrouwen op de prijs, korting, verzendkosten of totaal die door de browser worden gestuurd. Een gebruiker kan deze gemakkelijk manipuleren. De server moet alles opnieuw berekenen op basis van de product-SKU's, promotieregels en verzendmethode.

De kwaliteit van de implementatie hangt af van factoren zoals:

• Een idempotency-sleutel om te voorkomen dat een bestelling dubbel wordt aangemaakt of gecaptured.
• Database-transacties en locking om te voorkomen dat er te veel wordt verkocht (oversell).
• Het loggen van betalingspogingen vóórdat de betalingsprovider wordt aangeroepen.
• Verificatie van de webhook-handtekening.
• Een duidelijke checkout-state-machine.
• Een 'reconciliatie'-proces voor het geval dat PayPal een betaling registreert, maar de eigen site het antwoord niet ontvangt.

1.7 Reviews, nieuwsbrief, contact en tracking

Deze endpoints maken van de backend een volwaardige commerciële applicatie.

• Reviews: Deze moeten een status hebben (in afwachting, goedgekeurd, afgewezen). Spambeveiliging, rate limiting en verificatie van aankoop zijn belangrijk. Het endpoint

  POST /api/reviews/<id>

  voor het aanmaken van een review is verwarrend; een nieuwe API zou een duidelijker resource-naamgevingsschema moeten gebruiken.
• Nieuwsbrief: Belangrijk zijn het normaliseren van e-mailadressen, een unique constraint, een optie voor double opt-in (afhankelijk van de wetgeving, zoals de AVG), een eenvoudige uitschrijfmogelijkheid en het niet onnodig opslaan van e-mails in platte tekst.
• Contact: Dit endpoint heeft CAPTCHA of een andere vorm van botbescherming nodig, rate limiting, een wachtrij voor het versturen van e-mails en mag niet direct afhankelijk zijn van een e-mailprovider voor de HTTP-respons.
• Track order: Het is onveilig om bestellingen te laten opzoeken met een eenvoudig, kort volgnummer. De beste praktijk is een signed tracking token of een combinatie van een orderreferentie met het e-mailadres of de postcode, in combinatie met rate limiting. Een openbaar endpoint is anders eenvoudig te 'scrapen' en kan leiden tot datalekken van privacygevoelige informatie.

1.8 Analytics en tracking

Het endpoint

POST /api/track

Het is echter cruciaal dat dit endpoint geen willekeurige JSON accepteert en deze voor altijd opslaat. De event-namen en eigenschappen moeten worden goedgekeurd ('whitelist'), de payload moet worden beperkt in grootte, en persoonlijke gegevens (PII) moeten worden gehasht of weggelaten. Gebeurtenissen moeten via een wachtrij worden verwerkt om de webserver niet te belasten.

1.9 Waarschijnlijke backend-stack

• Node.js (Express/Fastify/NestJS): Dit is een voor de hand liggende kandidaat, omdat React/Vite-projecten vaak in het JavaScript/TypeScript-ecosysteem blijven. Het server-side inbedden van window.__INITIAL_DATA__ is ook eenvoudig met Node.js. Dit is echter een aanname op basis van het ecosysteem, geen bewijs.
• PHP (Laravel/Symfony): PHP is nog steeds een zeer reële mogelijkheid. Laravel is uitstekend geschikt voor REST-controllers, database-migraties, queues en e-mail. Ook PHP kan de Vite-app-shell serveren vanaf een catch-all-route.
• Python (FastAPI/Flask/Django): Ook Python is goed mogelijk. FastAPI en Flask zijn lichtgewicht voor REST-API's, en Django heeft een krachtige ORM en admin-interface.

Conclusie: Er is niet genoeg bewijs om de backend-taal met zekerheid vast te stellen. Een definitieve uitspraak kan alleen worden gedaan na het bestuderen van deployment-bestanden, lockfiles, container-images, response-headers (voordat ze door Cloudflare worden gewist), cookie-prefixen of database-drivers.

1.10 Sterke punten van de huidige architectuur

• Platform-onafhankelijke UI: React is niet gebonden aan een PHP-thema of de paginacyclus van WooCommerce. De gehele weergavelaag staat los van de backend.
• Uitstekende asset-caching: De Vite-build genereert bestandsnamen met hashes. Hierdoor kan de CDN de assets voor onbepaalde tijd cachen (

  Cache-Control: immutable

  ). Bij een nieuwe deployment krijgen bestanden een nieuwe naam, waardoor er geen cache hoeft te worden gepurged.
• Doelgericht CMS: De homepage- en layout-bouwer zijn precies toegespitst op wat de winkel nodig heeft, zonder de complexiteit van een algemene page-builder.
• Duidelijk API-domein: De catalogus-, content- en operationele API's kunnen afzonderlijk worden gebruikt voor de webwinkel, een mobiele app of een ander kanaal.
• Minder afhankelijk van plugins: Dit vermindert de kans op conflicten en de 'vendor lock-in' die vaak bij platforms als WooCommerce optreedt.
• Snelle navigatie na eerste lading: De SPA-ervaring zorgt voor vloeiende overgangen.

1.11 Zwakke punten en risico's

• Eerste lading is traag: Een gebruiker moet wachten tot alle JavaScript is gedownload, geparseerd en uitgevoerd voordat hij inhoud ziet. Op een zwak netwerk of een trage telefoon kan dit lang duren.
• API-waterfall: Als de instellingen, homepage, layout en producten na elkaar worden opgehaald, ontstaat er een 'waterval' die de Largest Contentful Paint (LCP) aanzienlijk vertraagt.
• SEO en statuscodes: De catch-all app-shell leidt snel tot soft 404's en problemen met indexering voor Google en sociale media (die vaak geen JavaScript uitvoeren).
• Complexe cache-invalidatie: De catalogus, homepage, layout en instellingen hebben allemaal verschillende vervaltermijnen (TTL's). Te lang cachen leidt tot verouderde informatie; te kort cachen belast de server onnodig.
• Zelfgebouwde bedrijfslogica: Kortingen, bestellingen, belastingen, retouren, voorraadbeheer, webhooks en een beheerpaneel moeten allemaal zelf worden gebouwd en getest. Dit is een groot project.
• Niet-genormaliseerd datamodel: De voorraad op productniveau in plaats van op variantniveau is een recept voor problemen bij het groeien van het productassortiment.
• Beveiligingsrisico's: Contact-, review-, nieuwsbrief-, tracking- en betalingsendpoints zijn allemaal openbare endpoints die zorgvuldig moeten worden beveiligd tegen misbruik.
• 'Bus factor': Als slechts één persoon de volledige kennis van deze maatwerkbackend en -builder heeft, is het risico groot. De kosten voor het inwerken van een nieuwe ontwikkelaar zijn aanzienlijk hoger dan bij een standaardplatform.

2. Directe vergelijking met WooCommerce

2.1 Is een maatwerk SPA 'beter' dan WooCommerce?

Nee, dat is niet te zeggen op basis van alleen de technologie. 'Maatwerk' geeft meer controle, maar maakt een site niet automatisch sneller, veiliger, beter vindbaar in Google of goedkoper. De kwaliteit hangt af van het datamodel, de rendering-strategie (SSR vs CSR), de cache, monitoring en het testen.

Voor een catalogus van slechts 16 producten kan een maatwerkarchitectuur een overkill zijn. Het kan een strategisch voordeel zijn voor het merk, maar het kan ook een dure oplossing zijn voor eenvoudige behoeften zoals orderbeheer, kortingen en rapportages.

2.2 Snelheid en laadtijd

• Maatwerk SPA: Heeft het potentieel om bij volgende pagina's extreem snel te zijn (alleen data wordt opgehaald). De eerste lading is echter het zwakke punt: deze is vaak traag door het opstarten van de JavaScript-app en de waterval aan API-verzoeken. Het ophalen van alle 500 producten in één keer wordt een groot knelpunt bij een grotere catalogus.
• WooCommerce: De initiële HTML bevat alle content, dus de pagina is meteen zichtbaar. Met goede caching, een CDN en een snelle server kan WooCommerce ook zeer snel zijn. Het nadeel is dat dynamische pagina's (winkelwagen, account) moeilijker te cachen zijn.

Conclusie: Een goed geoptimaliseerde maatwerkoplossing kan sneller zijn. WooCommerce heeft een eenvoudiger vertrekpunt. De enige eerlijke manier om te vergelijken is door de Core Web Vitals (p75) op mobiel te meten, de TTFB van de server, de JavaScript-grootte en de API-latentie.

2.3 Ontwerpvrijheid (UI) en bouwer

• Maatwerk React: Wint ruimschoots als het merk een unieke ervaring nodig heeft met speciale animaties, lay-outs of campagnepagina's die niet in een standaard thema passen. De zelfgebouwde homepage-bouwer is compacter en makkelijker te gebruiken dan een algemene page-builder omdat deze maar 10-15 blokken bevat.
• WooCommerce: Wint op het gebied van 'time-to-market' en het beheerpaneel. Productbeheer, orderbeheer, kortingssystemen en rapportages zijn direct beschikbaar. Om hetzelfde niveau van beheer te krijgen, moet je voor een maatwerkoplossing een compleet beheerpaneel bouwen.

2.4 SEO (Zoekmachineoptimalisatie)

Traditionele WooCommerce heeft een groot voordeel: de product- en categoriepagina's worden als volledige HTML door de server gegenereerd. Google kan deze pagina's direct indexeren.

Een pure client-side SPA (CSR) is niet per definitie onvindbaar, maar brengt wel risico's met zich mee:

• De initiële HTML bevat geen productnaam, beschrijving, prijs of gestructureerde data (JSON-LD).
• Titel, canonical URL en Open Graph-tags worden pas na het laden van JavaScript toegevoegd, waardoor sociale media de verkeerde informatie kunnen tonen.
• Foutieve URL's krijgen een 200-status in plaats van een 404.
• Als de API niet werkt of te traag is, ziet Google een lege pagina.
• Links die met JavaScript worden gegenereerd, zijn voor Google lastiger te volgen dan echte

  <a href>

  -tags.

Google beschouwt 'dynamic rendering' (het serveren van een statische versie aan bots) als een tijdelijke oplossing, niet als een structurele verbetering . De aanbevolen aanpak is server-side rendering (SSR).

Wat moet er in een nieuwe implementatie worden gedaan?

1. Gebruik SSG/ISR (Static Site Generation / Incremental Static Regeneration) voor product-, categorie- en contentpagina's zodat de HTML al de volledige inhoud bevat.
2. Gebruik SSR voor pagina's die per verzoek data nodig hebben.
3. Gebruik CSR alleen voor interactieve elementen zoals de winkelwagen of persoonlijke aanbevelingen.
4. Genereer metadata (title, description, canonical, Open Graph) en gestructureerde data (JSON-LD) aan de serverkant.
5. Stuur echte HTTP-statuscodes (200, 404, 410).
6. Zorg voor een XML-sitemap, duidelijke robots.txt en correcte redirects.
7. Test de site met een crawler die geen JavaScript uitvoert, en controleer de Search Console.

2.5 Onderhoud

• Maatwerk: Je moet de frontend, backend, database, beheerpaneel, API-contracten, betalingsintegratie en deployment zelf onderhouden. Een kleine wijziging in een veld kan grote gevolgen hebben. Dit vereist een sterk team.
• WooCommerce: De kernecommerce en het beheerpaneel worden onderhouden door een community. De onderhoudskosten verschuiven echter naar het updaten van de WordPress-kern, de WooCommerce-plugin, het thema en alle andere plugins. Elke update vereist een test op een staging-omgeving vanwege mogelijke conflicten.

Conclusie: WooCommerce ruilt de kosten van 'zelfbouwen' in voor de kosten van 'ecosysteembeheer'. Maatwerk ruilt de plugin-kosten in voor engineering-salaris.

2.6 Hostingkosten

Een kleine WooCommerce-site kan op een enkele managed WordPress-host draaien. Een maatwerk SPA heeft een goedkope frontend (statische bestanden op een CDN), maar het totale systeem (API-server, database, object-opslag, e-mailservice, wachtrijen, logs) vereist al snel meerdere services. Maatwerk is dus niet per definitie goedkoper. Bij laag bezoek zijn de personeelskosten vaak hoger dan de serverkosten.

2.7 Schaalbaarheid

Een maatwerk, headless architectuur (frontend los van backend) kan eenvoudiger worden geschaald. De frontend, API en database kunnen onafhankelijk van elkaar worden opgeschaald. Dit is een voordeel bij campagnes met veel piekverkeer. De echte bottleneck zit echter niet in de webserver, maar in de database-transacties tijdens het bestelproces.

WooCommerce kan, met goede hosting, caching en een getunede database, ook aanzienlijk verkeer aan. Voor een winkel met 16 producten is schaalbaarheid in dit stadium waarschijnlijk geen issue.

2.8 Afhankelijkheid van plugins en leveranciers

WooCommerce is sterk afhankelijk van plugins. Dit brengt risico's met zich mee op het gebied van licentiekosten, verouderde plugins en conflicten. Maatwerk vermindert deze afhankelijkheid, maar niet de afhankelijkheid van frameworks, npm-pakketten, clouddiensten en de kennis van het eigen team.

2.9 Beslissingstabel

2.10 Conclusie en aanbeveling voor de keuze

• Kies WooCommerce als het doel is om snel te lanceren met een klein team, een standaard winkelproces en geen extreem unieke gebruikerservaring vereist is.
• Blijf bij maatwerk als het doel is om een unieke merkervaring te bieden, een eigen builder te hebben, meerdere verkoopkanalen te integreren en het team over de juiste backend-kennis beschikt. Vervang dan wel de pure SPA door een framework met SSR/ISR.
• 'Headless WooCommerce' (WooCommerce als backend met een aparte frontend) wordt niet aanbevolen, tenzij er een duidelijke noodzaak is voor een unieke UI of multi-channel verkoop. Het combineert namelijk de nadelen van beide werelden.

De beste richting voor deze specifieke site: Blijf bij de maatwerk commerce-aanpak, maar herschrijf de storefront fundamenteel met een hybride rendering-strategie. De unieke builder en merk-UI zijn kerncompetenties; de problemen zitten in de rendering, het datamodel, de correctheid van de checkout en het operationele beheer. Het overschakelen naar WooCommerce wordt alleen aangeraden als het team de capaciteit mist om het maatwerk te onderhouden.

3. Richtlijnen voor een nieuwe implementatie (herschrijving)

3.1 Principes

De nieuwe source code moet de bedrijfsvereisten en data overnemen, maar mag geen gedecompileerde bundles, module-structuren, private symbolen of oude implementaties kopiëren.

Wel overnemen (universele ideeën):

• Catalogus/categorie/product detail.
• Hompage als blokken-systeem.
• Layout met header/footer/navigatie.
• Kortingen, nieuwsbrief, contactformulier, reviews, tracking.
• PayPal create/approve/capture flow.
• Verzendstaffels en winkelinstellingen.

Vernieuwen (opnieuw bouwen):

• Route-naamgeving en response-formaten.
• Database-model (varianten, voorraad).
• Component-register en bouwer-schema.
• Rendering-strategie.
• Checkout state-machine.
• Cache-invalidatie strategie.
• Beveiliging, monitoring en test-suite.

3.2 Voorgestelde technische stack

Storefront (Frontend):

• Next.js App Router + React + TypeScript: Voor server components, SSR, static generation (ISR) en client-components alleen voor interactie. Dit is geen dogma; Remix of een ander SSR-framework is ook geschikt. Het doel is server-gerenderde HTML, correcte statuscodes en minimale client-side JavaScript.
• Zod: Voor typeveilige validatie op de grensvlakken (API requests/responses).
• TanStack Query: Alleen voor server-side state die op de client moet worden ververst, niet voor data die al is gerenderd.
• CSS Modules/Tailwind: Een design-token systeem met minimale runtime CSS-in-JS.
• Geoptimaliseerde afbeeldingen: Via de CDN/object-opslag met expliciete breedte- en formaatparameters.

Backend:

• NestJS (Fastify adapter) + TypeScript of Fastify: Een modulaire, schaalbare backend.
• PostgreSQL: Als de 'source of truth' voor alle data.
• Drizzle ORM of Prisma: Voor type-safe database-toegang, queries en migraties. Complexe transacties (voorraad, betalingen) moeten nog steeds handmatig worden ontworpen.
• Redis: Alleen voor cache, distributed locking, rate limiting of sessiebeheer. Dit is niet nodig bij een klein project.
• BullMQ (of vergelijkbare wachtrij): Voor het verwerken van e-mails, webhooks, analytics en andere achtergrondtaken.
• S3-compatibele objectopslag: Voor media (afbeeldingen, video's). De database slaat alleen de metadata en de sleutel op.
• OpenTelemetry + Gestructureerde logs + Foutopsporing: Om verzoeken, transacties en betalingen te kunnen traceren.

Deployment:

• De storefront draait achter een CDN/edge cache.
• De API draait in een aparte container/service.
• Gebruik een managed PostgreSQL-database met 'point-in-time recovery'.
• Objectopslag is gescheiden van het container-bestandssysteem.
• Maak een aparte staging-omgeving met een PayPal sandbox.
• Bewaar geheimen (API keys, wachtwoorden) in een 'secret manager', niet in de repository.