En ecommerce-plattform du ikke trenger å slåss mot

Velg en av topp-10 commerce SaaS-plattformene og se på API-dokumentasjonen deres. Se så på admin-UI-en deres. Funksjonene stemmer ikke. Adminen kan ting API-et ikke kan. Verre, plattform-leverandøren vet det — og betrakter det som en feature, ikke en bug. Å låse kapabiliteter bak adminen er det som holder deg på plattformen deres. I det øyeblikket du kan gjøre alt via API, kan du også gå.

Det er den fundamentale spenningen. De store SaaS-plattformene (Shopify, BigCommerce, Wix Commerce) optimaliserer for ikke-tekniske merchants fordi det er det meste av TAM-en deres. Når utviklere ber om en webhook på en spesifikk event, en måte å registrere et custom checkout-steg, eller skriveadgang til en tidligere read-only ressurs, er svaret typisk „oppgrader til enterprise-tier“ eller „bruk Zapier“.

Axnify er bygget annerledes fordi backenden er strukturert for det. Hvert domene er en mikrotjeneste (product, order, cart, theme, billing, asset, customer, payment, shipping osv.) med eget database-skjema og eget HTTP-API. Admin-UI-en er en frontend som snakker med disse APIene — akkurat som koden din gjør. Det finnes ingen admin-only-kapabilitet. Det finnes ingen „intern endpoint“ du ikke kan kalle. API-overflaten ER plattformen.

Den designbeslutningen har konsekvenser. Det betyr at Axnify er ærligere om hva den støtter og ikke støtter: hvis det ikke er i API-et, eksisterer det ikke. Det betyr at breaking changes fanges raskere — du kan ikke shippe en admin-feature uten å også shippe API-et. Og det betyr at du som utvikler som integrerer mot plattformen, aldri er i posisjonen til å måtte skrive en screen-scraper fordi adminen kan noe koden din ikke kan.

Den klassiske ecommerce-plattform-arkitekturen — Shopify, Magento, WooCommerce — er én monolittisk codebase som kjører mot én database. Det gjør plattformen rask å bygge i starten og lett å resonnere om for små butikker. Det betyr også at hver feature deler samme runtime, samme database-connection-pool og samme release-syklus. Når plattform-teamet shipper en ny feature, får hver merchant den (eller buggen som kom med) samme dag.

Axnify tar den motsatte tilnærmingen. Hvert commerce-domene lever i sin egen Go-mikrotjeneste. product-tjenesten eier produkter, varianter, options og lager. order-tjenesten eier ordrer, line items og fulfillments. cart-tjenesten eier aktive handlekurver. asset-tjenesten eier fil-lagring. theme-tjenesten eier themes, sider, sections og blocks. Det er over 20 slike tjenester totalt, hver med eget PostgreSQL-skjema, eget migrations-katalog, egne tester, hver uavhengig deploybar.

Tjenester kommuniserer over HTTP med internal-key authentication for service-to-service-kall og JWT/X-Tenant-ID for kall fra sluttbrukere. Delte bekymringer (auth, tenant-resolution, rate limiting, logging, metrics, error tracking) bor i en delt middleware-pakke som hver tjeneste importerer. PostgreSQL er delt, men skjemaer er isolert; en tjeneste kan JOIN mot en annens tabeller via views, men skrivinger går gjennom den eiende tjenestens API.

For deg som utvikler som integrerer mot plattformen, har denne arkitekturen praktiske implikasjoner. APIer er stabile per-tjeneste: product-API-et utvikler seg i eget tempo, order-API-et i sitt eget. Webhooks kommer fra tjenesten som eier eventen, med rike metadata om hvilken tjeneste som sendte ut hva. Ytelse er begrenset per-domene: en treig rapport-query i analytics-tjenesten kan ikke blokkere order-create-kallet ditt. Og debugging er enklere fordi hver request bærer en request-ID som logges på tvers av hver tjeneste den rører.