Ecommerce-alusta, jota vastaan ei tarvitse taistella

Valitse mikä tahansa top-10 commerce SaaS-alustoista ja katso niiden API-dokumentaatiota. Katso sitten heidän admin-UI:taan. Toiminnot eivät täsmää. Admin pystyy asioihin, joihin API ei pysty. Pahempaa, alustan toimittaja tietää tämän — ja pitää sitä featurena, ei buginä. Kykyjen lukitseminen adminin taakse on se, mikä pitää sinut heidän alustallaan. Sillä hetkellä, kun voit tehdä kaiken API:n kautta, voit myös lähteä.

Tämä on perustavanlaatuinen jännite. Suuret SaaS-alustat (Shopify, BigCommerce, Wix Commerce) optimoivat ei-teknisille kauppiaille, koska he muodostavat suurimman osan TAM:sta. Kun kehittäjät pyytävät webhookia tietylle tapahtumalle, tapaa rekisteröidä custom-checkout-vaihe tai kirjoitusoikeutta aiemmin read-only-resurssiin, vastaus on yleensä „päivitä enterprise-tieriin“ tai „käytä Zapieria“.

Axnify on rakennettu eri tavalla, koska sen backend on strukturoitu sitä varten. Jokainen domain on mikropalvelu (product, order, cart, theme, billing, asset, customer, payment, shipping jne.) omalla tietokantakaavalla ja omalla HTTP-API:lla. Admin-UI on frontend, joka puhuu näille API:ille — täsmälleen samalla tavalla kuin koodisi. Ei ole admin-only-kykyä. Ei ole „sisäistä endpointia“, jota et voisi kutsua. API-pinta ON alusta.

Tällä suunnittelupäätöksellä on seurauksia. Se tarkoittaa, että Axnify on rehellisempi siitä, mitä se tukee ja mitä ei: jos sitä ei ole API:ssa, sitä ei ole olemassa. Se tarkoittaa, että breaking change-t saadaan kiinni nopeammin — et voi shipata admin-featurea shippaamatta myös API:a. Ja se tarkoittaa, että sinä kehittäjänä, joka integroi alustaa vastaan, et koskaan ole tilanteessa, jossa joudut kirjoittamaan screen-scraperin, koska admin osaa jotain, mitä koodisi ei osaa.

Klassinen ecommerce-alustan arkkitehtuuri — Shopify, Magento, WooCommerce — on yksi monoliittinen codebase, joka pyörii yhtä tietokantaa vastaan. Tämä tekee alustasta nopean rakentaa alkuvaiheessa ja helpon ymmärtää pienille kaupoille. Se tarkoittaa myös, että jokainen feature jakaa saman runtimen, saman tietokannan connection poolin ja saman release-syklin. Kun alusta-tiimi shippaa uuden featuren, jokainen kauppias saa sen (tai sen mukana tulleen bugin) samana päivänä.

Axnify ottaa päinvastaisen lähestymistavan. Jokainen commerce-domain elää omassa Go-mikropalvelussaan. product-palvelu omistaa tuotteet, variantit, optionit ja varaston. order-palvelu omistaa tilaukset, line itemit ja fulfillmentit. cart-palvelu omistaa aktiiviset ostoskorit. asset-palvelu omistaa tiedostojen tallennuksen. theme-palvelu omistaa teemat, sivut, sectionit ja blockit. Tällaisia palveluita on yli 20 kaikkiaan, kukin omalla PostgreSQL-kaavalla, omalla migraatiohakemistolla, omilla testeillä, kukin itsenäisesti deployable.

Palvelut kommunikoivat HTTP:n yli käyttäen internal-key-autentikaatiota service-to-service-kutsuille ja JWT/X-Tenant-ID:tä loppukäyttäjästä peräisin oleville kutsuille. Jaetut huolet (auth, tenant-resoluutio, rate limiting, logging, metrics, error tracking) elävät jaetussa middleware-paketissa, jonka jokainen palvelu importoi. PostgreSQL on jaettu, mutta kaavat ovat eristettyjä; palvelu voi JOIN-ata toisen palvelun tauluja vastaan views-näkymien kautta, mutta kirjoitukset menevät omistavan palvelun API:n läpi.

Sinulle kehittäjänä, joka integroi alustaa vastaan, tällä arkkitehtuurilla on käytännön seurauksia. API:t ovat vakaita per-palvelu: product-API kehittyy omassa tahdissaan, order-API omassaan. Webhookit tulevat palvelusta, joka omistaa tapahtuman, runsailla metadatoilla siitä, mikä palvelu lähetti mitä. Suorituskyky on rajoitettu per-domain: hidas raporttikysely analytics-palvelussa ei voi blokata order-create-kutsuasi. Ja debuggaus on helpompaa, koska jokainen request kantaa request ID:tä, joka logataan jokaisessa palvelussa, johon se koskee.