Uma plataforma ecommerce contra a qual não tens de lutar

Escolhe qualquer uma das 10 maiores plataformas de commerce SaaS e olha para a sua documentação de API. Depois olha para o seu UI de admin. As funcionalidades não batem certo. O admin pode fazer coisas que a API não pode. Pior, o fornecedor da plataforma sabe-o — e considera isto uma feature, não um bug. Trancar capacidades atrás do admin é o que te mantém na plataforma deles. No momento em que podes fazer tudo via API, também podes ir-te embora.

Esta é a tensão fundamental. As grandes plataformas SaaS (Shopify, BigCommerce, Wix Commerce) optimizam para comerciantes não técnicos porque são a maior parte do seu TAM. Quando os programadores pedem um webhook num evento específico, uma forma de registar um passo de checkout custom, ou acesso de escrita a um recurso até aí só de leitura, a resposta é normalmente «sobe ao tier enterprise» ou «usa Zapier».

A Axnify é construída de forma diferente porque o seu backend está estruturado para isso. Cada domínio é um microsserviço (product, order, cart, theme, billing, asset, customer, payment, shipping, etc.) com o seu próprio schema de base de dados e a sua própria API HTTP. O UI de admin é um frontend que fala com essas APIs — exactamente da mesma forma que o teu código. Não há capacidades admin-only. Não há «endpoint interno» que não possas chamar. A superfície da API É a plataforma.

Essa decisão de design tem consequências. Significa que a Axnify é mais honesta sobre o que suporta e o que não suporta: se não está na API, não existe. Significa que as breaking changes são apanhadas mais cedo — não consegues lançar uma feature de admin sem lançar também a API. E significa que tu, como programador a integrar contra a plataforma, nunca estás na posição de escrever um screen-scraper porque o admin consegue fazer algo que o teu código não consegue.

A arquitectura clássica de plataforma ecommerce — Shopify, Magento, WooCommerce — é uma única codebase monolítica a correr contra uma única base de dados. Isto torna a plataforma rápida de construir no início e fácil de raciocinar para lojas pequenas. Também significa que cada feature partilha o mesmo runtime, o mesmo connection pool de base de dados e o mesmo ciclo de release. Quando a equipa da plataforma lança uma nova feature, cada comerciante recebe-a (ou o bug que veio com ela) no mesmo dia.

A Axnify segue a abordagem oposta. Cada domínio commerce vive no seu próprio microsserviço Go. O serviço product detém produtos, variantes, opções e inventário. O serviço order detém encomendas, linhas e fulfillments. O serviço cart detém os carrinhos activos. O serviço asset detém o armazenamento de ficheiros. O serviço theme detém temas, páginas, sections e blocos. Há mais de 20 serviços assim no total, cada um com o seu próprio schema PostgreSQL, a sua própria directoria de migrações, os seus próprios testes, cada um deployable independentemente.

Os serviços comunicam por HTTP usando autenticação com chave interna para chamadas service-to-service e JWT/X-Tenant-ID para chamadas originadas por end-user. As preocupações partilhadas (auth, resolução de tenant, rate limiting, logging, métricas, error tracking) vivem num package middleware partilhado que cada serviço importa. O PostgreSQL é partilhado mas os schemas estão isolados; um serviço pode fazer JOIN contra as tabelas de outro via views, mas as escritas passam pela API do serviço dono.

Para ti como programador a integrar contra a plataforma, esta arquitectura tem implicações práticas. As APIs são estáveis por serviço: a API product evolui ao seu próprio ritmo, a API order ao seu. Os webhooks vêm do serviço que detém o evento, com metadados ricos sobre que serviço emitiu o quê. A performance está limitada por domínio: uma query de relatório lenta no serviço de analytics não pode bloquear a tua chamada order-create. E o debugging é mais fácil porque cada request leva um request ID logado em cada serviço que toca.