Ecommerce platforma, s ktorou nemusíš bojovať

Vyber si akúkoľvek z top 10 commerce SaaS platforiem a pozri sa na ich dokumentáciu API. Potom sa pozri na ich admin UI. Funkcionalita nesedí. Admin vie veci, ktoré API nevie. Horšie: dodávateľ platformy to vie — a považuje to za feature, nie za bug. Zamykanie schopností za adminom je to, čo ťa drží na ich platforme. Vo chvíli, keď vieš všetko cez API, môžeš aj odísť.

To je fundamentálne napätie. Veľké SaaS platformy (Shopify, BigCommerce, Wix Commerce) optimalizujú pre netechnických obchodníkov, lebo tí tvoria väčšinu ich TAM. Keď vývojári žiadajú webhook na konkrétnu udalosť, spôsob ako zaregistrovať vlastný krok checkoutu alebo zápisový prístup k dosiaľ read-only zdroju, odpoveď je zvyčajne „upgraduj na enterprise tier“ alebo „použi Zapier“.

Axnify je postavená inak, lebo jej backend je na to štruktúrovaný. Každá doména je mikroservis (product, order, cart, theme, billing, asset, customer, payment, shipping atď.) s vlastnou databázovou schémou a vlastným HTTP API. Admin UI je frontend, ktorý hovorí s týmito API — presne tak, ako to robí tvoj kód. Nie je žiadna admin-only schopnosť. Nie je žiadny „interný endpoint“, ktorý by si nemohol zavolať. Plocha API JE platforma.

To dizajnové rozhodnutie má dôsledky. Znamená, že Axnify je úprimnejšia o tom, čo podporuje a čo nie: ak to nie je v API, neexistuje to. Znamená, že breaking changes sa chytia rýchlejšie — nemôžeš dodať admin feature bez toho, aby si dodal API. A znamená, že ty ako vývojár integrujúci sa s platformou nikdy nie si v pozícii, keď musíš písať screen-scraper, lebo admin vie niečo, čo tvoj kód nevie.

Klasická architektúra ecommerce platformy — Shopify, Magento, WooCommerce — je jediná monolitická codebase bežiaca proti jedinej databáze. To robí platformu rýchlu na počiatočnú stavbu a ľahkú na uvažovanie pre malé obchody. Tiež to znamená, že každá feature zdieľa rovnaký runtime, rovnaký connection pool databázy a rovnaký release cyklus. Keď tím platformy dodá novú feature, každý obchodník ju dostane (alebo bug, ktorý s ňou prišiel) v rovnaký deň.

Axnify volí opačný prístup. Každá commerce doména žije vo svojom vlastnom Go mikroservise. Service product vlastní produkty, varianty, opcie a sklad. Service order vlastní objednávky, line items a fulfillmenty. Service cart vlastní aktívne košíky. Service asset vlastní úložisko súborov. Service theme vlastní témy, stránky, sekcie a bloky. Celkom je takých servisov 20+, každý s vlastnou PostgreSQL schémou, vlastným adresárom migrácií, vlastnými testami, každý nezávisle nasaditeľný.

Services komunikujú cez HTTP s použitím internal-key autentizácie pre service-to-service volania a JWT/X-Tenant-ID pre volania od koncových používateľov. Zdieľané záujmy (auth, rozlíšenie tenantu, rate limiting, logovanie, metriky, error tracking) žijú v zdieľanom middleware balíčku, ktorý každý service importuje. PostgreSQL je zdieľaný, ale schémy sú izolované; service môže JOINovať proti tabuľkám iného cez views, ale zápisy idú cez API vlastniaceho service.

Pre teba ako vývojára integrujúceho proti platforme má táto architektúra praktické dôsledky. API sú stabilné per-service: API product sa vyvíja svojím tempom, API order svojím. Webhooky prichádzajú zo service, ktorý udalosť vlastní, s bohatými metadátami o tom, ktorý service čo emitoval. Výkon je obmedzený per-doména: pomalý reportný dotaz v analytics service nemôže zablokovať tvoj order-create call. A debugovanie je ľahšie, lebo každý request nesie request ID logované cez každý service, ktorého sa dotkne.