Een webshop van nul bouwen met logistieke integratie: de vijf lagen en in welke volgorde je ze bouwt

"Ik wil een online shop die van nul is gebouwd" betekent meestal "ik wil een shop die doet wat sjablonen niet doen". En wat sjablonen niet doen, is bijna altijd hetzelfde: praten met wie produceert, met wie verzendt en met wie int, zonder dat iemand gegevens van het ene scherm naar het andere overtypt. Dit artikel legt uit hoe wij dat werk in vijf lagen opdelen, wat elke laag bevat en in welke volgorde ze worden gebouwd. De voorbeelden komen van eclipseando.com, een eigen shop van ons die in productie draait, en van de vervoerdersconnectoren die we voor Odoo hebben gepubliceerd.

De vijf lagen van een shop

Laag 1: de data leeft op één plek

Voordat je ook maar één scherm tekent, moet je beslissen waar de catalogus leeft. Heeft de klant Odoo, dan is het antwoord Odoo: producten, prijzen, voorraad en bestellingen staan daar en de website leest ze, kopieert ze niet. Heeft de klant Odoo niet, dan heeft de shop een eigen database nodig, en die houd je liefst klein en saai. Bij eclipseando.com is dat SQLite, in één bestand, met back-up. Wat niet mag gebeuren, is dat de prijs op de website staat, ook in een spreadsheet en ook in het ERP: na twee maanden zijn het drie verschillende prijzen.

Laag 2: de kassa vertrouwt de browser niet

Twee regels waar we niet over onderhandelen. De eerste: de prijs wordt op de server berekend, met de geldende catalogus, op het moment dat de betaalsessie wordt aangemaakt. De browser mag het winkelmandje bewaren, maar mag niet zeggen hoeveel iets kost. De tweede: een bestelling is betaald wanneer de betaalprovider dat bevestigt met een ondertekende webhook, niet wanneer de klant op de bedankpagina landt. Bij Stripe is dat checkout.session.completed met geverifieerde handtekening; bij andere betaalproviders heet het anders, maar het idee is hetzelfde. En als de volgende stap mislukt wanneer de webhook binnenkomt, antwoord je met een fout zodat de betaalprovider het opnieuw probeert, en bewaar je de sessie-id zodat je nooit twee keer produceert.

Laag 3: elke leverancier praat zoals hij kan

Hier houdt "logistieke integratie" op een woord te zijn en wordt het werk. Een leverancier met API en webhook (een print-on-demandbedrijf, een grote vervoerder) integreer je in beide richtingen: je maakt de bestelling aan bij betaling en luistert naar zijn melding "verzonden" om de tracking aan de klant door te geven. Een leverancier met een dropshipping-API integreer je in één richting en bevraag je in de andere: vóór het afrekenen de echte beschikbaarheid per land, daarna de bestelling. En een leverancier zonder API, en die zijn er veel, integreer je door het menselijk werk terug te brengen tot één klik: het systeem maakt precies de e-mail of het CSV-bestand dat de leverancier nodig heeft, en als zijn pakketten met een vervoerder gaan die e-mails verstuurt, worden die e-mails gelezen en omgezet in statussen.

Twee details die je alleen leert met echte bestellingen. Eén: de tracking hoort bij de zending, niet bij de bestelling, want een bestelling met twee producten van twee leveranciers zijn twee pakketten. Twee: de levertijden uit de documentatie van de leverancier zijn niet die hij haalt; je meet ze door testbestellingen aan te maken en te lezen wat er terugkomt, en die tonen we de klant vóór de betaling. Is de leverancier een vervoerder en draait de shop op Odoo, dan is dit allemaal al opgelost in de vervoerdersconnectoren die we publiceren: label, tracking, manifest en retour in de levering zelf.

Laag 4: wat vanzelf draait en wat opnieuw wordt geprobeerd

Een shop heeft werk dat er niet van mag afhangen dat iemand eraan denkt: de e-mailwachtrij leegmaken, betaalde bestellingen opnieuw proberen die de leverancier niet bereikten, de mailbox van de vervoerder uitlezen, de voorraad synchroniseren met marketplaces. Elk daarvan is een geplande taak met een interval en een logboek. De ontwerpregel is dat geen enkele taak een externe dienst aanroept in het pad van een gebruikersverzoek: de pagina leest wat de taak in de cache heeft achtergelaten. Zo blijft de shop pagina's tonen als de leverancier om drie uur 's nachts uitvalt, en worden de bestellingen opnieuw geprobeerd zodra hij terug is.

Laag 5: de frontend, als laatste en snel

Als de vier onderliggende lagen opgelost zijn, is de frontend het dankbaarste deel. We geven de voorkeur aan statische sites die tijdens de build worden gegenereerd (Astro bij eclipseando.com) en door nginx of Caddy worden geserveerd: ze laden razendsnel, hebben geen database om aan te vallen en kosten wat een kleine server kost. Het dynamische deel (winkelmandje, betaling, orderstatus) loopt via een aparte API. Meertaligheid doe je met één URL per taal en eigen teksten, niet met een automatische vertaler erbovenop, en je test dat met tests die controleren of elk sjabloon in alle talen bestaat. En de snelheid meet je vóór publicatie: paginagewicht, afbeeldingen op de grootte waarin ze worden getoond, niets dat de eerste render blokkeert.

De volgorde telt: van binnen naar buiten

De duurste fout die we zien, is beginnen bij laag 5. In week twee wordt een mooie website getoond, de klant raakt enthousiast, en de lagen 1 tot en met 4 worden er haastig onder geïmproviseerd. Het resultaat werkt tot de eerste bestelling met twee leveranciers, of tot de eerste verloren webhook. Wij bouwen andersom: eerst de data en de kassa met hun tests, daarna de integraties met echte testbestellingen, daarna de geplande taken, en de frontend als laatste, wanneer precies bekend is wat hij moet tonen. Het kost evenveel tijd. Er wordt veel minder herwerkt.

Veelgestelde vragen

Nuttige links binnen FlexigoTech

Wat wij hierover doen