Ecommerce platforma, se kterou nemusíš bojovat

Vyber si libovolnou z top 10 commerce SaaS platforem a podívej se na jejich dokumentaci API. Pak se podívej na jejich admin UI. Funkcionalita nesedí. Admin umí věci, které API neumí. Co je horší, dodavatel platformy to ví — a považuje to za feature, ne za bug. Zamykání schopností za adminem je to, co tě drží na jejich platformě. Ve chvíli, kdy umíš všechno přes API, můžeš taky odejít.

To je fundamentální napětí. Velké SaaS platformy (Shopify, BigCommerce, Wix Commerce) optimalizují pro netechnické obchodníky, protože ti tvoří většinu jejich TAM. Když vývojáři žádají webhook na konkrétní událost, způsob, jak zaregistrovat vlastní krok checkoutu, nebo zápisový přístup k dosud read-only zdroji, odpověď je obvykle „upgraduj na enterprise tier“ nebo „použij Zapier“.

Axnify je postavena jinak, protože její backend je k tomu strukturován. Každá doména je mikroservis (product, order, cart, theme, billing, asset, customer, payment, shipping atd.) s vlastním databázovým schématem a vlastním HTTP API. Admin UI je frontend, který mluví s těmito API — přesně tak, jak to dělá tvůj kód. Není žádná admin-only schopnost. Není žádný „interní endpoint“, který bys nemohl zavolat. Plocha API JE platforma.

To designové rozhodnutí má důsledky. Znamená, že Axnify je upřímnější o tom, co podporuje a co ne: pokud to není v API, neexistuje to. Znamená, že breaking changes se chytí rychleji — nemůžeš dodat admin feature, aniž bys dodal API. A znamená, že ty jako vývojář integrující se s platformou nikdy nejsi v pozici, kdy musíš psát screen-scraper, protože admin umí něco, co tvůj kód neumí.

Klasická architektura ecommerce platformy — Shopify, Magento, WooCommerce — je jediná monolitická codebase běžící proti jediné databázi. To dělá platformu rychlou na počáteční stavbu a snadnou na uvažování pro malé obchody. Také to znamená, že každá feature sdílí stejný runtime, stejný connection pool databáze a stejný release cyklus. Když tým platformy dodá novou feature, každý obchodník ji dostane (nebo bug, který s ní přišel) ve stejný den.

Axnify volí opačný přístup. Každá commerce doména žije ve svém vlastním Go mikroservisu. Service product vlastní produkty, varianty, opce a sklad. Service order vlastní objednávky, line items a fulfillmenty. Service cart vlastní aktivní košíky. Service asset vlastní úložiště souborů. Service theme vlastní motivy, stránky, sekce a bloky. Celkem je takových servisů 20+, každý s vlastním PostgreSQL schématem, vlastním adresářem migrací, vlastními testy, každý nezávisle nasaditelný.

Services komunikují přes HTTP s použitím internal-key autentizace pro service-to-service volání a JWT/X-Tenant-ID pro volání od koncových uživatelů. Sdílené zájmy (auth, rozlišení tenantu, rate limiting, logování, metriky, error tracking) žijí ve sdíleném middleware balíčku, který každý service importuje. PostgreSQL je sdílený, ale schémata jsou izolovaná; service může JOINovat proti tabulkám jiného přes views, ale zápisy jdou přes API vlastnícího service.

Pro tebe jako vývojáře integrujícího proti platformě má tato architektura praktické důsledky. API jsou stabilní per-service: API product se vyvíjí svým tempem, API order svým. Webhooky přicházejí ze service, který událost vlastní, s bohatými metadaty o tom, který service co emitoval. Výkon je omezený per-doména: pomalý reportní dotaz v analytics service nemůže zablokovat tvůj order-create call. A debugování je snadnější, protože každý request nese request ID logované přes každý service, kterého se dotkne.