Ecommerce платформа, срещу която не трябва да се бориш

Избери която и да е от топ 10 commerce SaaS платформи и виж тяхната документация на API. После виж техния admin UI. Функционалностите не съвпадат. Admin-ът може неща, които API не може. По-лошо: вендорът на платформата го знае — и счита това за feature, а не за bug. Заключването на възможности зад admin-а е това, което те държи на тяхната платформа. В момента, в който можеш да правиш всичко през API, можеш и да си тръгнеш.

Това е фундаменталното напрежение. Големите SaaS платформи (Shopify, BigCommerce, Wix Commerce) оптимизират за нетехнически търговци, защото те са по-голямата част от техния TAM. Когато разработчиците искат webhook за конкретно събитие, начин да регистрират персонализирана стъпка на checkout, или достъп за запис към преди това read-only ресурс, отговорът обикновено е „качи се на enterprise tier“ или „използвай Zapier“.

Axnify е изградена по различен начин, защото backend-ът ѝ е структуриран за това. Всеки домейн е микросървис (product, order, cart, theme, billing, asset, customer, payment, shipping и т.н.) със собствена база от данни и собствено HTTP API. Admin UI-ът е frontend, който говори с тези API-та — точно по същия начин, по който го прави твоят код. Няма admin-only възможности. Няма „вътрешен endpoint“, който не можеш да извикаш. Повърхността на API-то Е платформата.

Това дизайнерско решение има последствия. Означава, че Axnify е по-честна за това какво поддържа и какво не: ако не е в API-то, не съществува. Означава, че breaking changes се хващат по-бързо — не можеш да пуснеш admin feature, без да пуснеш API. И означава, че ти като разработчик, който интегрира срещу платформата, никога не си в позицията да пишеш screen-scraper, защото admin-ът може нещо, което твоят код не може.

Класическата архитектура на ecommerce платформа — Shopify, Magento, WooCommerce — е една монолитна codebase, която работи срещу една база данни. Това прави платформата бърза за начално изграждане и лесна за разбиране за малки магазини. Също означава, че всяка функционалност споделя същия runtime, същия connection pool на базата данни и същия release цикъл. Когато екипът на платформата пуска нова функционалност, всеки търговец я получава (или bug-а, който дойде с нея) в същия ден.

Axnify избира противоположния подход. Всеки commerce домейн живее в собствен Go микросървис. product сървисът притежава продукти, варианти, опции и инвентар. order сървисът притежава поръчки, line items и fulfillments. cart сървисът притежава активни колички. asset сървисът притежава съхранение на файлове. theme сървисът притежава теми, страници, секции и блокове. Общо има над 20 такива сървиса, всеки със собствена PostgreSQL схема, собствена директория за миграции, собствени тестове, всеки независимо разгръщаем.

Сървисите комуникират през HTTP с използване на internal-key автентикация за service-to-service извиквания и JWT/X-Tenant-ID за извиквания, произхождащи от краен потребител. Споделените грижи (auth, разрешение на tenant, rate limiting, логване, метрики, error tracking) живеят в споделен middleware пакет, който всеки сървис импортира. PostgreSQL е споделен, но схемите са изолирани; сървис може да JOIN-ва срещу таблиците на друг през views, но записите минават през API-то на притежаващия сървис.

За теб като разработчик, интегриращ срещу платформата, тази архитектура има практически последствия. API-тата са стабилни per-сървис: product API еволюира със собствено темпо, order API със своето. Webhooks идват от сървиса, който притежава събитието, с богати метаданни за това кой сървис какво е излъчил. Производителността е ограничена per-домейн: бавна заявка за отчет в analytics сървиса не може да блокира твоето order-create извикване. И debug-ването е по-лесно, защото всяка заявка носи request ID, който се логва във всеки сървис, който докосва.