Platforma ecommerce, z którą nie musisz walczyć

Wybierz dowolną z 10 największych platform commerce SaaS i spójrz na ich dokumentację API. Potem spójrz na ich admin UI. Funkcjonalności się nie zgadzają. Admin może robić rzeczy, których nie może API. Co gorsza, dostawca platformy o tym wie — i uważa to za feature, nie za bug. Blokowanie możliwości za adminem to to, co trzyma cię na ich platformie. W momencie, w którym możesz zrobić wszystko przez API, możesz też odejść.

To fundamentalne napięcie. Duże platformy SaaS (Shopify, BigCommerce, Wix Commerce) optymalizują pod nietechnicznych merchantów, bo to większość ich TAM. Kiedy deweloperzy proszą o webhook na konkretne zdarzenie, sposób na zarejestrowanie customowego kroku checkoutu, albo dostęp do zapisu do wcześniej read-only zasobu, odpowiedź zwykle brzmi „przejdź na tier enterprise” albo „użyj Zapiera”.

Axnify jest zbudowana inaczej, bo jej backend jest pod to skonstruowany. Każda domena to mikroserwis (product, order, cart, theme, billing, asset, customer, payment, shipping itd.) z własnym schematem bazy danych i własnym HTTP API. Admin UI to frontend, który rozmawia z tymi API — dokładnie tak samo jak twój kod. Nie ma możliwości admin-only. Nie ma „wewnętrznego endpointa”, którego nie możesz wywołać. Powierzchnia API JEST platformą.

Ta decyzja projektowa ma konsekwencje. Oznacza, że Axnify jest uczciwsza co do tego, co wspiera, a czego nie: jeśli nie ma tego w API, to nie istnieje. Oznacza, że breaking changes są wyłapywane szybciej — nie możesz wypuścić feature'a do admina bez wypuszczenia API. I oznacza, że ty, jako deweloper integrujący się z platformą, nigdy nie jesteś w sytuacji, w której musisz pisać screen-scraper, bo admin potrafi coś, czego nie potrafi twój kod.

Klasyczna architektura platformy ecommerce — Shopify, Magento, WooCommerce — to pojedyncza monolityczna codebase działająca przeciw jednej bazie danych. To sprawia, że platforma jest szybka do zbudowania na początku i łatwa do rozumowania dla małych sklepów. Oznacza też, że każda feature dzieli ten sam runtime, ten sam connection pool bazy danych i ten sam cykl release'ów. Kiedy zespół platformy wypuszcza nową feature, każdy merchant dostaje ją (albo buga, który z nią przyszedł) tego samego dnia.

Axnify idzie odwrotną drogą. Każda domena commerce żyje we własnym mikroserwisie Go. Serwis product jest właścicielem produktów, wariantów, opcji i magazynu. Serwis order jest właścicielem zamówień, line items i fulfillmentów. Serwis cart jest właścicielem aktywnych koszyków. Serwis asset jest właścicielem przechowywania plików. Serwis theme jest właścicielem motywów, stron, sekcji i bloków. W sumie jest ponad 20 takich serwisów, każdy z własnym schematem PostgreSQL, własnym katalogiem migracji, własnymi testami, każdy wdrażalny niezależnie.

Serwisy komunikują się przez HTTP z użyciem autentykacji kluczem internal dla wywołań service-to-service i JWT/X-Tenant-ID dla wywołań od end-userów. Wspólne troski (auth, rozstrzyganie tenanta, rate limiting, logowanie, metryki, error tracking) żyją w wspólnym pakiecie middleware, który importuje każdy serwis. PostgreSQL jest wspólny, ale schematy są izolowane; serwis może JOINować się do tabel innego przez views, ale zapisy idą przez API serwisu-właściciela.

Dla ciebie jako dewelopera integrującego się z platformą ta architektura ma praktyczne konsekwencje. API są stabilne per-serwis: API product ewoluuje we własnym tempie, API order we własnym. Webhooki przychodzą z serwisu, który jest właścicielem zdarzenia, z bogatymi metadanymi o tym, który serwis co wyemitował. Wydajność jest ograniczona per-domena: wolne zapytanie raportu w serwisie analytics nie może zablokować twojego wywołania order-create. A debugowanie jest łatwiejsze, bo każdy request niesie request ID, który jest logowany w każdym serwisie, którego dotknął.