Eine Ecommerce-Plattform, gegen die du nicht kämpfen musst

Such dir eine der Top-10-Commerce-SaaS-Plattformen aus und sieh dir ihre API-Dokumentation an. Dann sieh dir ihr Admin-UI an. Die Features stimmen nicht überein. Das Admin kann Dinge, die die API nicht kann. Schlimmer noch: der Plattformanbieter weiß das — und betrachtet es als Feature, nicht als Bug. Fähigkeiten hinter dem Admin einzuschließen, hält dich auf ihrer Plattform. In dem Moment, in dem du alles über die API erledigen kannst, kannst du auch gehen.

Das ist die fundamentale Spannung. Die großen SaaS-Plattformen (Shopify, BigCommerce, Wix Commerce) optimieren für nicht-technische Händler, weil das den Großteil ihres TAM ausmacht. Wenn Entwickler nach einem Webhook für ein bestimmtes Event fragen, nach einer Möglichkeit, einen eigenen Checkout-Schritt zu registrieren, oder nach Schreibzugriff auf eine bisher schreibgeschützte Ressource, lautet die Antwort meist „Upgrade auf das Enterprise-Tier“ oder „Nutze Zapier“.

Axnify ist anders gebaut, weil das Backend dafür strukturiert ist. Jede Domain ist ein Microservice (product, order, cart, theme, billing, asset, customer, payment, shipping usw.) mit eigenem Datenbankschema und eigener HTTP-API. Das Admin-UI ist ein Frontend, das mit diesen APIs spricht — exakt so, wie es dein Code tut. Es gibt keine admin-only-Fähigkeit. Es gibt keinen „internen Endpoint“, den du nicht aufrufen kannst. Die API-Fläche IST die Plattform.

Diese Designentscheidung hat Konsequenzen. Sie bedeutet, dass Axnify ehrlicher darin ist, was es unterstützt und was nicht: was nicht in der API ist, existiert nicht. Sie bedeutet, dass Breaking Changes schneller auffallen — du kannst kein Admin-Feature shippen, ohne auch die API zu shippen. Und sie bedeutet, dass du als Entwickler, der gegen die Plattform integriert, nie in der Lage bist, einen Screen-Scraper zu schreiben, weil das Admin etwas kann, was dein Code nicht kann.

Die klassische Ecommerce-Plattform-Architektur — Shopify, Magento, WooCommerce — ist eine einzige monolithische Codebase, die gegen eine einzige Datenbank läuft. Das macht die Plattform initial schnell zu bauen und einfach für kleine Shops zu verstehen. Es bedeutet auch, dass jedes Feature dieselbe Runtime, denselben Datenbank-Connection-Pool und denselben Release-Zyklus teilt. Wenn das Plattform-Team ein neues Feature shippt, bekommt es jeder Händler (oder den Bug, der mitkam) am selben Tag.

Axnify wählt den entgegengesetzten Weg. Jede Commerce-Domain lebt in ihrem eigenen Go-Microservice. Der product-Service besitzt Produkte, Varianten, Optionen und Inventar. Der order-Service besitzt Bestellungen, Line Items und Fulfillments. Der cart-Service besitzt aktive Warenkörbe. Der asset-Service besitzt die Dateispeicherung. Der theme-Service besitzt Themes, Seiten, Sections und Blocks. Insgesamt gibt es 20+ solcher Services, jeder mit eigenem PostgreSQL-Schema, eigenem Migrations-Verzeichnis, eigenen Tests, jeder unabhängig deploybar.

Services kommunizieren über HTTP, wobei Internal-Key-Authentifizierung für Service-zu-Service-Calls und JWT/X-Tenant-ID für End-User-Calls verwendet werden. Geteilte Belange (Auth, Tenant-Resolution, Rate-Limiting, Logging, Metrics, Error-Tracking) leben in einem geteilten Middleware-Paket, das jeder Service importiert. PostgreSQL ist geteilt, aber Schemas sind isoliert; ein Service kann gegen Tabellen eines anderen via Views JOINen, aber Writes gehen durch die API des besitzenden Service.

Für dich als Entwickler, der gegen die Plattform integriert, hat diese Architektur praktische Implikationen. APIs sind pro-Service stabil: die product-API entwickelt sich in ihrem eigenen Tempo, die order-API in ihrem eigenen. Webhooks kommen vom Service, der das Event besitzt, mit reichen Metadaten darüber, welcher Service was emittiert hat. Performance ist pro-Domain begrenzt: eine langsame Report-Query im analytics-Service kann deinen order-create-Call nicht blockieren. Und Debugging ist einfacher, weil jeder Request eine Request-ID trägt, die über jeden berührten Service hinweg geloggt wird.