En ecommerce-plattform du inte behöver slåss mot

Välj någon av topp-10 commerce SaaS-plattformarna och titta på deras API-dokumentation. Titta sedan på deras admin-UI. Funktionerna matchar inte. Adminen kan saker API:t inte kan. Värre, plattform-leverantören vet det — och betraktar det som en feature, inte en bug. Att låsa kapabiliteter bakom adminen är det som håller dig på deras plattform. I det ögonblicket du kan göra allt via API kan du också gå.

Det är den fundamentala spänningen. De stora SaaS-plattformarna (Shopify, BigCommerce, Wix Commerce) optimerar för icke-tekniska merchants eftersom det utgör det mesta av deras TAM. När utvecklare ber om en webhook på en specifik event, ett sätt att registrera ett custom checkout-steg, eller skrivåtkomst till en tidigare read-only resurs är svaret oftast „uppgradera till enterprise-tier“ eller „använd Zapier“.

Axnify är byggt annorlunda eftersom backenden är strukturerad för det. Varje domän är en mikrotjänst (product, order, cart, theme, billing, asset, customer, payment, shipping osv.) med eget databasschema och eget HTTP-API. Admin-UI:t är en frontend som pratar med dessa APIer — precis som din kod gör. Det finns ingen admin-only-kapabilitet. Det finns ingen „intern endpoint“ du inte kan anropa. API-ytan ÄR plattformen.

Det designvalet har konsekvenser. Det betyder att Axnify är mer ärlig om vad den stöder och inte stöder: om det inte finns i API:t finns det inte. Det betyder att breaking changes fångas snabbare — du kan inte skicka en admin-feature utan att också skicka API:t. Och det betyder att du som utvecklare som integrerar mot plattformen aldrig är i positionen att behöva skriva en screen-scraper för att adminen kan något din kod inte kan.

Den klassiska ecommerce-plattform-arkitekturen — Shopify, Magento, WooCommerce — är en enda monolitisk codebase som kör mot en enda databas. Det gör plattformen snabb att bygga i början och lätt att resonera kring för små butiker. Det betyder också att varje feature delar samma runtime, samma databas-connection-pool och samma release-cykel. När plattform-teamet skickar en ny feature får varje merchant den (eller buggen som kom med) samma dag.

Axnify tar det motsatta angreppssättet. Varje commerce-domän lever i sin egen Go-mikrotjänst. product-tjänsten äger produkter, varianter, options och lager. order-tjänsten äger ordrar, line items och fulfillments. cart-tjänsten äger aktiva varukorgar. asset-tjänsten äger fil-lagring. theme-tjänsten äger themes, sidor, sections och blocks. Det finns över 20 sådana tjänster totalt, var och en med eget PostgreSQL-schema, eget migrations-katalog, egna tester, var och en oberoende deploybar.

Tjänster kommunicerar över HTTP med internal-key authentication för service-to-service-anrop och JWT/X-Tenant-ID för anrop från slutanvändare. Delade angelägenheter (auth, tenant-resolution, rate limiting, logging, metrics, error tracking) bor i ett delat middleware-paket som varje tjänst importerar. PostgreSQL är delat men scheman är isolerade; en tjänst kan JOIN mot en annans tabeller via views, men skrivningar går genom den ägande tjänstens API.

För dig som utvecklare som integrerar mot plattformen har denna arkitektur praktiska implikationer. APIer är stabila per-tjänst: product-API:t utvecklas i egen takt, order-API:t i sin egen. Webhooks kommer från tjänsten som äger eventen, med rik metadata om vilken tjänst som emitterade vad. Prestanda är begränsad per-domän: en långsam rapport-query i analytics-tjänsten kan inte blockera ditt order-create-anrop. Och debugging är enklare eftersom varje request bär ett request-ID som loggas över varje tjänst den rör.