Roadmap técnico · Firebase → backend próprio

Plano de Migração — Sign CRM

De SPA estática ligada direto no Firebase para uma arquitetura com backend próprio, banco relacional e isolamento real de dados por empresa.

Atualizado 07/07/2026 Escopo Frontend + Backend + Dados Execução Incremental, módulo por módulo
Contexto

O sistema atual funciona e está em produção, mas a segurança depende só de checagens feitas no navegador. Qualquer usuário autenticado consegue, em teoria, ler e escrever dados de outra empresa. Este plano existe pra corrigir isso trazendo a lógica de autorização e os dados pra um backend que o cliente nunca acessa diretamente.

As 5 mudanças

01 — Estrutura

Separar frontend e backend

  • Duas aplicações no mesmo repositório: /frontend e /backend
  • Comunicação só via endpoints HTTP (API REST) — nunca import direto de código de um lado no outro
  • Essa regra sozinha já deixa o sistema pronto pra virar múltiplos serviços (ex: app mobile) no futuro, sem reescrever nada

02 — Backend

Node.js + TypeScript

  • Reaproveita a lógica que já existe hoje: cálculo de orçamento, fluxo de status do trabalho, geração de PDF
  • Node.js sozinho é só o runtime, não um framework — quem expõe os endpoints é o NestJS, que roda por cima do Express (trocável por Fastify) e já organiza módulos e injeção de dependência

03 — Dados

PostgreSQL no lugar do Firestore

  • Cada empresa isolada por workspace_id, checado em toda query no backend
  • Autorização (quem é admin, quem está pendente ou bloqueado) validada no servidor — não mais só no navegador
  • ORM: Prisma — o mais usado do mercado hoje, type-safe. Fica escondido atrás de uma interface de repositório na camada de domínio, pra regra de negócio nunca depender do ORM diretamente

04 — Frontend

React

  • Reescreve a interface atual em componentes
  • Fala só com a API do backend — nunca acessa banco de dados direto
  • Validações no frontend são só de UX (campo obrigatório, formato) — nunca regra de negócio; tudo é revalidado no backend

05 — Arquitetura interna

Clean Architecture + Hexagonal no backend

  • Camadas separadas: domínio (regras de negócio) → aplicação (casos de uso) → infraestrutura (banco, HTTP)
  • Regra de negócio testável sem precisar de banco rodando
  • Trocar peças no futuro — banco, framework, adicionar app mobile — sem tocar na regra de negócio
Regra

Validação acontece nos dois lados, mas com papéis diferentes: o backend é dono da regra de negócio (camada de domínio) e revalida tudo, sempre. O frontend só desenha e valida UX — campo obrigatório, formato, feedback imediato — nunca decide regra de negócio, e nenhuma validação do frontend é confiável sozinha.

Idioma

Todo o código é escrito em inglês (variáveis, funções, tabelas, endpoints, commits), sem exceção. O backend responde sempre em inglês — mensagens de erro e chaves de tradução, nunca texto traduzido fixo. O frontend decide o idioma de exibição — padrão pelo navegador do cliente, com opção de escolha manual — reaproveitando o módulo de i18n que já existe.

06 — Ordem de execução

1

Modelar as tabelas do Postgres

A partir dos dados que já existem hoje no Firestore.

2

Montar o esqueleto do backend

Camadas do Clean Architecture + primeiro endpoint funcionando: autenticação.

3

Migrar módulo por módulo

Clientes → Trabalhos → Gastos → Inventário → o resto. Nunca tudo de uma vez.

4

Manter o sistema atual no ar

Até cada módulo novo estar validado — sem cliente sentir a transição.

5

Corrigir a segurança já na arquitetura nova

Isolamento por empresa, validação server-side, página pública de aprovação passando a depender de um token real salvo no banco — não de parâmetros na URL.