Savaşmak zorunda olmadığın bir ecommerce platformu

İlk 10 commerce SaaS platformundan herhangi birini seç ve API dokümantasyonuna bak. Sonra admin UI'larına bak. Özellikler eşleşmez. Admin'in API'nin yapamadığı şeyleri yapabilir. Daha kötüsü, platform sağlayıcısı bunu bilir — ve bunu bir bug değil, bir feature olarak görür. Yetenekleri admin'in arkasına kilitlemek seni onların platformunda tutan şeydir. Her şeyi API üzerinden yapabildiğin an, ayrılabilirsin de.

Temel gerilim budur. Büyük SaaS platformları (Shopify, BigCommerce, Wix Commerce) teknik olmayan satıcılar için optimize eder çünkü TAM'lerinin çoğu odur. Geliştiriciler belirli bir olay için webhook, özel bir checkout adımı kaydetme yolu veya daha önce sadece okunabilir olan bir kaynağa yazma erişimi istediğinde, cevap genellikle „enterprise tier'a yükselt" veya „Zapier kullan" olur.

Axnify farklı inşa edilmiştir çünkü backend'i bunun için yapılandırılmıştır. Her domain bir mikroservistir (product, order, cart, theme, billing, asset, customer, payment, shipping vb.), kendi veritabanı şemasıyla ve kendi HTTP API'siyle. Admin UI bu API'lerle konuşan bir frontend'dir — tıpkı kodunun yaptığı gibi. Admin-only yetenek yoktur. Çağıramayacağın bir „dahili endpoint" yoktur. API yüzeyi platformdur.

Bu tasarım kararının sonuçları vardır. Bu, Axnify'ın neyi destekleyip neyi desteklemediği konusunda daha dürüst olduğu anlamına gelir: API'de yoksa, yok demektir. Breaking change'lerin daha hızlı yakalandığı anlamına gelir — API'yi de göndermeden bir admin özelliği gönderemezsin. Ve platforma karşı entegre eden bir geliştirici olarak senin, admin'in kodunun yapamadığı bir şeyi yapabildiği için screen-scraper yazmak zorunda kalacağın bir konuma asla düşmeyeceğin anlamına gelir.

Klasik ecommerce platform mimarisi — Shopify, Magento, WooCommerce — tek bir veritabanına karşı çalışan tek bir monolitik kod tabanıdır. Bu, platformu başlangıçta hızlı inşa edilebilir ve küçük mağazalar için akıl yürütmesi kolay yapar. Aynı zamanda her özelliğin aynı runtime'ı, aynı veritabanı bağlantı havuzunu ve aynı release döngüsünü paylaştığı anlamına gelir. Platform ekibi yeni bir özellik gönderdiğinde her satıcı onu (ya da onunla gelen bug'ı) aynı gün alır.

Axnify tam tersi yaklaşımı benimser. Her commerce domain'i kendi Go mikroservisinde yaşar. product servisi ürünleri, varyantları, opsiyonları ve envanteri sahiplenir. order servisi siparişleri, satır kalemlerini ve fulfillment'ları sahiplenir. cart servisi aktif sepetleri sahiplenir. asset servisi dosya depolamayı sahiplenir. theme servisi temaları, sayfaları, bölümleri ve blokları sahiplenir. Toplamda bu tür 20+ servis vardır, her biri kendi PostgreSQL şemasıyla, kendi migration dizinleriyle, kendi testleriyle, her biri bağımsız olarak deploy edilebilir.

Servisler service-to-service çağrıları için internal-key kimlik doğrulaması ve son kullanıcı kaynaklı çağrılar için JWT/X-Tenant-ID kullanarak HTTP üzerinden iletişim kurar. Paylaşılan endişeler (auth, tenant çözümleme, rate limiting, loglama, metrikler, error tracking) her servisin import ettiği paylaşılan bir middleware paketinde yaşar. PostgreSQL paylaşılır ama şemalar izolasyonludur; bir servis view'ler aracılığıyla başka bir servisin tablolarına JOIN yapabilir, ancak yazmalar sahip servisin API'sinden geçer.

Platforma karşı entegre eden bir geliştirici olarak senin için bu mimarinin pratik sonuçları vardır. API'ler servis başına kararlıdır: product API'si kendi hızında, order API'si kendi hızında gelişir. Webhook'lar olayı sahiplenen servisten gelir, hangi servisin neyi yayınladığına dair zengin metadata ile. Performans domain başına sınırlıdır: analytics servisindeki yavaş bir rapor sorgusu order-create çağrını bloklayamaz. Ve debug daha kolaydır çünkü her request, dokunduğu her serviste loglanan bir request ID taşır.