En ecommerce-platform du ikke skal kæmpe imod

Vælg en af de top-10 commerce SaaS-platforme og kig på deres API-dokumentation. Kig så på deres admin-UI. Funktionerne stemmer ikke overens. Adminen kan ting, som API'en ikke kan. Værre, platform-leverandøren ved det — og betragter det som en feature, ikke en bug. At låse kapabiliteter bag adminen er det, der holder dig på deres platform. I det øjeblik du kan gøre alt via API, kan du også gå.

Det er den fundamentale spænding. De store SaaS-platforme (Shopify, BigCommerce, Wix Commerce) optimerer for ikke-tekniske merchants, fordi det er størstedelen af deres TAM. Når udviklere beder om en webhook på en bestemt event, en måde at registrere et custom checkout-trin, eller skriveadgang til en tidligere read-only ressource, er svaret typisk „opgrader til enterprise-tier“ eller „brug Zapier“.

Axnify er bygget anderledes, fordi backenden er struktureret til det. Hvert domæne er en mikroservice (product, order, cart, theme, billing, asset, customer, payment, shipping osv.) med sit eget database-skema og sit eget HTTP-API. Admin-UI'et er en frontend, der taler med disse APIer — præcis som din kode gør. Der er ingen admin-only kapabilitet. Der er ingen „intern endpoint“, du ikke kan kalde. API-overfladen ER platformen.

Den designbeslutning har konsekvenser. Det betyder, at Axnify er mere ærlig om, hvad den understøtter og ikke understøtter: hvis det ikke er i API'en, eksisterer det ikke. Det betyder, at breaking changes fanges hurtigere — du kan ikke shippe en admin-feature uden også at shippe API'en. Og det betyder, at du som udvikler, der integrerer mod platformen, aldrig er i den position, hvor du skal skrive en screen-scraper, fordi adminen kan noget, din kode ikke kan.

Den klassiske ecommerce-platform-arkitektur — Shopify, Magento, WooCommerce — er en enkelt monolitisk codebase, der kører mod en enkelt database. Det gør platformen hurtig at bygge i starten og let at ræsonnere om for små shops. Det betyder også, at hver feature deler samme runtime, samme database-connection-pool og samme release-cyklus. Når platform-teamet shipper en ny feature, får hver merchant den (eller den bug, der kom med) samme dag.

Axnify tager den modsatte tilgang. Hvert commerce-domæne lever i sin egen Go-mikroservice. product-servicen ejer produkter, varianter, options og lager. order-servicen ejer ordrer, line items og fulfillments. cart-servicen ejer aktive kurve. asset-servicen ejer fil-lagring. theme-servicen ejer themes, sider, sections og blocks. Der er over 20 sådanne services i alt, hver med eget PostgreSQL-skema, eget migrations-bibliotek, egne tests, hver uafhængigt deploybar.

Services kommunikerer over HTTP med internal-key authentication til service-to-service-kald og JWT/X-Tenant-ID til kald fra slutbrugere. Delte bekymringer (auth, tenant-resolution, rate limiting, logging, metrics, error tracking) lever i en delt middleware-pakke, som hver service importerer. PostgreSQL er delt, men skemaer er isolerede; en service kan JOIN mod en andens tabeller via views, men skriv går gennem den ejende services API.

For dig som udvikler, der integrerer mod platformen, har denne arkitektur praktiske implikationer. APIer er stabile per-service: product-API'en udvikler sig i eget tempo, order-API'en i sit eget. Webhooks kommer fra den service, der ejer eventen, med rige metadata om, hvilken service udsendte hvad. Performance er afgrænset per-domæne: en langsom rapport-query i analytics-servicen kan ikke blokere dit order-create-kald. Og debugging er nemmere, fordi hver request bærer et request-ID, der logges på tværs af hver service, den rører.