Egy ecommerce platform, amivel nem kell harcolnod

Válassz ki bármelyiket a top 10 commerce SaaS platform közül, és nézd meg az API dokumentációjukat. Aztán nézd meg az admin UI-t. A funkciók nem egyeznek. Az admin tud olyan dolgokat, amiket az API nem. Rosszabb, a platform szállítója ezt tudja — és ezt feature-nek tartja, nem bugnak. A képességek admin mögé zárása az, ami a platformjukon tart téged. Abban a pillanatban, hogy mindent meg tudsz csinálni API-n keresztül, el is mehetsz.

Ez a fundamentális feszültség. A nagy SaaS platformok (Shopify, BigCommerce, Wix Commerce) nem-műszaki kereskedőkre optimalizálnak, mert ők alkotják a TAM nagyobb részét. Amikor fejlesztők egy konkrét eseményre webhookot kérnek, egy módot egyedi checkout-lépés regisztrálására, vagy írási hozzáférést egy korábban csak olvasható erőforráshoz, a válasz általában „lépj enterprise tier-re” vagy „használj Zapier-t”.

Az Axnify máshogy épült, mert a backendje erre van strukturálva. Minden domain egy mikroszerviz (product, order, cart, theme, billing, asset, customer, payment, shipping stb.) saját adatbázis-sémával és saját HTTP API-val. Az admin UI egy frontend, ami ezekkel az API-kkal beszél — pontosan úgy, ahogy a kódod. Nincs admin-only képesség. Nincs „belső endpoint”, amit ne tudnál meghívni. Az API felülete A platform.

Ennek a tervezési döntésnek vannak következményei. Azt jelenti, hogy az Axnify őszintébb arról, mit támogat és mit nem: ha nincs az API-ban, nem létezik. Azt jelenti, hogy a breaking change-eket gyorsabban elkapják — nem tudsz admin feature-t kiszállítani anélkül, hogy API-t is szállítanál. És azt jelenti, hogy te, mint fejlesztő, aki a platformhoz integrálódik, sosem leszel abban a helyzetben, hogy screen-scrapert kelljen írnod, mert az admin tud valamit, amit a kódod nem.

A klasszikus ecommerce platform architektúra — Shopify, Magento, WooCommerce — egyetlen monolit codebase, ami egyetlen adatbázis ellen fut. Ez teszi a platformot gyorsan építhetővé kezdetben és könnyen átláthatóvá kis boltoknál. Azt is jelenti, hogy minden feature ugyanazt a runtime-ot, ugyanazt az adatbázis connection pool-t és ugyanazt a release ciklust osztja. Amikor a platform csapat új feature-t szállít, minden kereskedő megkapja (vagy a bugot, ami vele jött) ugyanazon a napon.

Az Axnify ellentétes megközelítést választ. Minden commerce domain saját Go mikroszervizben él. A product szerviz tulajdonolja a termékeket, variánsokat, opciókat és készletet. Az order szerviz tulajdonolja a rendeléseket, line itemeket és fulfillmenteket. A cart szerviz tulajdonolja az aktív kosarakat. Az asset szerviz tulajdonolja a fájltárolást. A theme szerviz tulajdonolja a témákat, oldalakat, szekciókat és blokkokat. Összesen több mint 20 ilyen szerviz van, mindegyik saját PostgreSQL sémával, saját migrációs könyvtárral, saját tesztekkel, mindegyik függetlenül deployolható.

A szervizek HTTP-n keresztül kommunikálnak internal-key autentikációval service-to-service hívásokhoz és JWT/X-Tenant-ID-val végfelhasználói eredetű hívásokhoz. A megosztott gondok (auth, tenant feloldás, rate limiting, logging, metrikák, error tracking) egy megosztott middleware csomagban élnek, amit minden szerviz importál. A PostgreSQL megosztott, de a sémák izoláltak; egy szerviz JOIN-olhat egy másik tábláihoz views-on keresztül, de az írások a tulajdonos szerviz API-ján mennek át.

Számodra mint a platformhoz integrálódó fejlesztő számára ennek az architektúrának praktikus következményei vannak. Az API-k per-szerviz stabilak: a product API saját ütemben fejlődik, az order API a sajátjában. A webhookok az eseményt tulajdonló szervizből jönnek, gazdag metaadatokkal arról, melyik szerviz mit bocsátott ki. A teljesítmény per-domain korlátozott: egy lassú jelentés lekérdezés az analytics szervizben nem tudja blokkolni az order-create hívásodat. És a debug egyszerűbb, mert minden request request ID-t hordoz, amit minden megérintett szervizben logolnak.