Gimba - Um app de compras sobre uma loja que não tinha API
Aplicativo de e-commerce B2B para iOS e Android, com a camada de integração construída sobre um sistema que só expunha procedures de banco.
Comprar suprimento pela empresa, do celular
A Gimba vende suprimentos para empresas. A operação já tinha loja virtual e já vendia pela web. O que faltava era o aplicativo, e o pedido inicial parecia simples: fazer o app iOS e Android e integrar com o back-end existente.
O desafio que apareceu na primeira semana
O back-end existente não tinha integração para consumir. A loja era um sistema em ASP.NET sobre SQL Server, e o acesso aos dados se dava por procedures de banco, não por endpoints. Cálculo de frete, listas de favoritos, cadastro de cliente: tudo vivia como procedure.
Ou seja, antes de existir aplicativo era preciso existir uma camada que traduzisse aquilo para algo que um app pudesse consumir. Isso mudou o centro de gravidade do projeto, que deixou de ser só front-end móvel.
- Dar forma de API a um sistema que expunha procedures. Trabalhar a seis mãos: front-end e camada de integração do lado da X-Apps, API do lado de outro fornecedor, e o sistema legado do lado da Gimba. Desenvolver inteiramente através da VPN do cliente, único caminho até o ambiente.
A camada que faltava
A solução foi um serviço próprio em Strapi sobre MongoDB, publicado em ambiente de homologação, atuando como agregador e intermediário: de um lado conversava com as procedures do SQL Server e com a API REST mantida pelo outro fornecedor, do outro entregava ao aplicativo um contrato estável.
Esse desenho resolveu três coisas de uma vez. Deu ao aplicativo uma interface previsível, mesmo com o legado mudando atrás. Permitiu montar respostas que o legado não montava, como o carrinho persistido usado no fechamento com cartão. E concentrou num só lugar a tradução entre o mundo do banco e o mundo do app.
O painel administrativo da operação, com controle de banners e de links de destaque, saiu do mesmo Strapi, sem sistema separado.
O que o aplicativo faz
O fluxo é de compra corporativa, e isso aparece nas escolhas.
- Entrar como empresa ou como pessoa. Login por CNPJ ou CPF, com cadastro de pessoa jurídica, e entrada também por Facebook e Google. Achar o produto. Lista de categorias, busca e leitura de código de barras pela câmera, que é como o comprador encontra o item que já usa. Listas e favoritos. O comprador corporativo repete pedido, então as listas são parte do fluxo, não um extra. Carrinho e checkout. Separação de itens iguais no carrinho, cupons de desconto e cálculo de frete. Pagar como a empresa paga. Boleto, com download do documento no próprio aplicativo, e cartão de crédito. Acompanhar. Meus pedidos, meus dados e edição de cadastro. Lojas físicas. Localização por geolocalização.
A VPN, e o que ela ensinou
Vale registrar o ponto que mais custou tempo no projeto, porque ele não aparece em nenhum diagrama de arquitetura: todo o desenvolvimento dependia da VPN do cliente para alcançar o ambiente.
A conexão caía em intervalos curtos, e cada queda derrubava o pool de conexões do banco e travava a camada de integração. O sintoma chegava como tempo limite, mas a causa era de rede.
A X-Apps diagnosticou e propôs a alternativa estrutural, uma conexão direta entre as duas redes, em vez de seguir tratando sintoma.
A lição que fica para projetos parecidos é simples: quando o ambiente do cliente é o único caminho até os dados, a estabilidade desse acesso é requisito de projeto, e não detalhe de infraestrutura. Ela precisa entrar no planejamento com o mesmo peso de uma funcionalidade.
Stack e práticas
- React Native com Expo para iOS e Android. Strapi sobre MongoDB como camada de integração e painel administrativo, em Node.js. Consumo das procedures do SQL Server do cliente e da API REST mantida pelo fornecedor parceiro. Docker e Kubernetes com orquestração em Rancher, publicado em nuvem. Esteira automatizada de build e deploy, com aviso de cada etapa no canal do projeto. Protótipo navegável em Adobe XD, homologado com a área de marketing do cliente antes do desenvolvimento. Sprints semanais com pacote de escopo por semana.
A especificação de servidor para o ambiente também foi entregue ao cliente, com requisitos de sistema, processamento, memória e disco dimensionados para a operação.
Seu sistema legado não fala com aplicativo?
Muito sistema que roda bem há anos não tem como ser consumido por um app, e isso não significa trocar o sistema. Significa construir a camada certa no meio. A X-Apps desenha e constrói essa ponte, mantendo o legado onde ele está.