Een ecommerce-platform waar je niet tegen hoeft te vechten

Pak een van de top-10 commerce SaaS-platforms en kijk naar hun API-documentatie. Kijk dan naar hun admin-UI. De features matchen niet. De admin kan dingen die de API niet kan. Erger nog: de platform-vendor weet dit — en beschouwt het als een feature, niet als een bug. Capabilities achter de admin opsluiten is wat je op hun platform houdt. Het moment dat je alles via API kunt, kun je ook weg.

Dat is de fundamentele spanning. De grote SaaS-platforms (Shopify, BigCommerce, Wix Commerce) optimaliseren voor niet-technische merchants omdat dat het grootste deel van hun TAM is. Wanneer developers vragen om een webhook op een specifiek event, een manier om een custom checkout-stap te registreren, of schrijftoegang tot een eerder read-only resource, is het antwoord meestal 'upgrade naar het enterprise-tier' of 'gebruik Zapier'.

Axnify is anders gebouwd omdat de backend daarvoor gestructureerd is. Elk domein is een microservice (product, order, cart, theme, billing, asset, customer, payment, shipping enz.) met een eigen database-schema en een eigen HTTP-API. De admin-UI is een frontend die met die API's praat — exact dezelfde manier waarop jouw code dat doet. Er is geen admin-only capability. Er is geen 'interne endpoint' die je niet kunt aanroepen. Het API-oppervlak IS het platform.

Die designkeuze heeft gevolgen. Het betekent dat Axnify eerlijker is over wat het wel en niet ondersteunt: als het niet in de API zit, bestaat het niet. Het betekent dat breaking changes sneller worden opgepikt — je kunt geen admin-feature shippen zonder ook de API te shippen. En het betekent dat jij, als developer die tegen het platform integreert, nooit in de positie zit dat je een screen-scraper moet schrijven omdat de admin iets kan wat jouw code niet kan.

De klassieke ecommerce-platform-architectuur — Shopify, Magento, WooCommerce — is een enkele monolithische codebase die tegen één database draait. Dit maakt het platform snel om in het begin te bouwen en makkelijk om over te redeneren voor kleine shops. Het betekent ook dat elke feature dezelfde runtime, dezelfde database-connection-pool en dezelfde release-cyclus deelt. Wanneer het platform-team een nieuwe feature shipt, krijgt elke merchant 'm (of de bug die ermee meekwam) op dezelfde dag.

Axnify neemt de tegenovergestelde aanpak. Elk commerce-domein leeft in z'n eigen Go-microservice. De product-service bezit producten, varianten, opties en voorraad. De order-service bezit orders, line items en fulfillments. De cart-service bezit actieve carts. De asset-service bezit file-storage. De theme-service bezit themes, pagina's, sections en blocks. Er zijn meer dan 20 van zulke services in totaal, elk met een eigen PostgreSQL-schema, eigen migrations-directory, eigen tests, elk onafhankelijk deploybaar.

Services communiceren over HTTP met internal-key-authenticatie voor service-to-service-calls en JWT/X-Tenant-ID voor end-user-originated calls. Gedeelde concerns (auth, tenant-resolutie, rate limiting, logging, metrics, error tracking) leven in een gedeeld middleware-package dat elke service importeert. PostgreSQL is gedeeld maar schemas zijn geïsoleerd; een service kan tegen tabellen van een ander JOINen via views, maar writes lopen via de API van de bezittende service.

Voor jou als developer die tegen het platform integreert, heeft deze architectuur praktische gevolgen. API's zijn per service stabiel: de product-API evolueert in z'n eigen tempo, de order-API in dat van zichzelf. Webhooks komen van de service die het event bezit, met rijke metadata over welke service wat emitte. Performance is per domein begrensd: een trage report-query in de analytics-service kan je order-create-call niet blokkeren. En debuggen is makkelijker omdat elke request een request-ID draagt die gelogd wordt over elke service die hij raakt.