A Arquitetura Oculta: O deep dive na stack que sustenta o ZapBooster

A premissa deste blog é construir em público e documentar tudo. Desde o dia zero, decidimos que a transparência precisava ser de nível de código. Nenhuma caixa preta.

Antes mesmo de lançarmos a primeira versão oficial, este post serve como uma dissecção completa da fundação que escolhemos. Abri os nossos arquivos package.json e expliquei por que cada ferramenta está lá e como estruturamos a base do ZapBooster.

1. O Frontend (Extensão Chrome)

Construir extensões para Chrome no padrão Manifest V3 do zero é doloroso. Escolhemos o Plasmo (v0.90), que atua como o Next.js das extensões. Ele cuida do HMR (Hot Module Replacement) e facilita a injeção de Content Scripts e Background Workers.

• UI Library: React 18 e Tailwind CSS. Tailwind nos permite iterar muito rápido direto no JSX.
• Animações: Framer Motion para micro-interações que dão aquele ar premium.
• Armazenamento: @plasmohq/storage. Em vez de lidar com a API nativa verbosa do chrome.storage.local, o Plasmo nos dá um hook limpo (useStorage) que reage a mudanças de estado globalmente.
• Processamento: Usamos a biblioteca xlsx direto no lado do cliente para parsear planilhas gigantes de Leads sem precisar enviar bytes desnecessários para o backend.

2. A Landing Page e Dashboard Web

A página onde você está lendo isso, bem como o dashboard web para gerenciamento, roda em um ambiente completamente diferente da extensão.

• Framework: Next.js 16 (App Router) com React 19. A geração estática e o roteamento baseado em arquivos do Next.js nos dão performance máxima e SEO imbatível.
• Estilização: Tailwind v4 (com PostCSS). O motor v4 do Tailwind é incrivelmente rápido e dispensa a configuração de arquivos massivos.
• Ícones: Lucide React, leves e consistentes com nosso design system.

3. O Backend (API Server)

Não queríamos um monolito em Express onde tudo vira macarrão. Fomos de NestJS (v11). O Nest impõe uma arquitetura baseada em Módulos, Controllers e Services (muito similar ao Angular ou Spring Boot). Se o módulo de Auth precisa falar com o de IA, a injeção de dependência cuida de tudo.

• Segurança & Proteção: Usamos @nestjs/throttler para Rate Limiting e helmet contra vulnerabilidades comuns de cabeçalhos HTTP.
• Billing: SDK nativo do Stripe. Por que Stripe e não plataformas de infoproduto? Porque o Stripe nos dá webhooks em tempo real e consolidação limpa para SaaS puro, permitindo upgrade e downgrade de assinaturas (Starter/Pro) sem dor de cabeça.

4. O Banco de Dados (Supabase)

Supabase foi o que mais nos economizou tempo. Ele não é apenas um banco PostgreSQL. Ele nos fornece o serviço de Autenticação inteiro e seguro de graça (por isso temos @supabase/supabase-js tanto no front quanto no back).

Mais importante que isso: Lógica no Banco (PL/pgSQL).

• RLS (Row-Level Security): Ninguém acessa dados de outro usuário na nossa API. A segurança está no nível do banco.
• Triggers: Temos um trigger handle_new_user que escuta novos signups e cria automaticamente a linha de faturamento e saldo de créditos no banco público.
• RPCs (Remote Procedure Calls): Debitar saldo de IA de forma segura no Node.js cria problemas de concorrência. Se dois disparos acontecem no mesmo milissegundo, a leitura do saldo pode ser a mesma, e o débito duplo falha. Nós criamos uma função deduct_ai_credits_v2 direto no PostgreSQL que executa de forma atômica. Resolvido o problema de Race Condition.

5. A Inteligência Artificial em Produção

No backend, temos o SDK da OpenAI instalado. "Ué, vocês não usam Gemini?" Sim. Nós usamos o SDK oficial da OpenAI, mas apontamos o baseUrl para a API da OpenRouter.

A OpenRouter é um roteador unificado que nos permite trocar de modelo dinamicamente (para o modelo gratuito ou de custo hiper-baixo mais rápido e eficiente do mercado, como variantes do Google e Llama) mudando apenas uma string.

O truque de Mestre no Rate Limit: APIs de IA têm limites severos de chamadas por minuto (Rate Limit). No nosso ai.service.ts, nós implementamos um sistema de Round-Robin Key Pooling. Cadastramos dezenas de chaves de API, e o NestJS gerencia qual chave usar. Se uma chave bate no limite (429 Too Many Requests), o serviço coloca ela em "quarentena temporária" com um temporizador (setTimeout) e imediatamente usa a próxima chave disponível. Isso garante 100% de estabilidade para os envios em massa dos nossos usuários, mesmo em picos astronômicos de acesso.

6. Atendimento (Crisp)

Para fechar o pacote de SaaS, integramos o Crisp Chat. SaaS sem suporte em tempo real gera churn. O Crisp carrega de forma assíncrona, não pesa as métricas de Core Web Vitals e resolve o problema central.

Isso é construir em público. Nenhuma "caixa preta". Se você tem dúvidas de como aplicar algo disso no seu SaaS, chama a gente lá no LinkedIn!