Todos os projetos

Ordem de Serviço

em produção

Sistema de ordens de serviço e orçamentos, em produção na operação de uma empresa náutica.

Código do cliente, privado. Posso apresentar o sistema numa entrevista.

Arquitetura do sistema de OS Uma SPA React no navegador, sem backend próprio. Páginas usam hooks, hooks usam repositórios, que são o único acesso ao banco. Um módulo de conexão abre um app Firebase por linha de negócio. Cada linha de negócio tem seu próprio Firebase Auth, Firestore e regras de segurança, isolados fisicamente. navegador · SPA React, sem backend próprio Páginas Hooks *Repositorio.ts conexao.ts único acesso ao banco testado com Firestore em memória 1 app Firebase por linha de negócio Linha de negócio A Linha de negócio B Firebase Auth Firestore regras de segurança Firebase Auth Firestore regras de segurança isolado
Uma linha de negócio, um projeto Firebase. O código é do cliente, por isso diagrama no lugar de screenshot.
tipo
Trabalho PJ
cliente
S Náutica Customização e Acessórios
período
jul 2026 – out 2026
stack
React 19 · TypeScript · Vite · Firebase Auth · Firestore · Vitest
testes
153 com Vitest, incluindo o acesso ao banco

O problema

A empresa precisava emitir e acompanhar ordens de serviço, cadastrar clientes e embarcações, faturar por mês e mandar orçamentos para o cliente aprovar, tudo isso em duas linhas de negócio que não podem misturar dados. Desenvolvi o sistema do zero entre julho e outubro de 2026, e ele roda hoje na operação.

O que ele faz

  • Emissão de OS com impressão em PDF e exportação para Excel.
  • Orçamentos enviados por link seguro: o cliente aprova online e o orçamento vira OS.
  • Cadastro de clientes e embarcações, faturamento mensal e painel com gráficos.

Decisões

  1. Numeração transacional

    O número de cada OS sai de um contador lido e incrementado dentro de uma transação do Firestore.

    Por quê: número de OS é documento da empresa. Se duas pessoas emitem ao mesmo tempo, uma das transações é refeita com o valor novo, e nunca saem duas OS com o mesmo número.

  2. Uma linha de negócio, um projeto Firebase

    Cada linha de negócio tem seu próprio projeto Firebase, com Auth e Firestore separados.

    Por quê: isolamento físico dos dados. Um filtro esquecido numa consulta não consegue vazar dados de uma empresa para a outra, porque eles nem estão no mesmo banco.

  3. Sem backend próprio, regras do Firestore como barreira

    A SPA fala direto com o Firebase. Quem pode ler e escrever o quê é decidido pelas regras de segurança do Firestore.

    Por quê: custo de infraestrutura zero, o que era requisito. Em troca, as regras viram a camada de segurança de verdade, e o custo de leitura do plano gratuito foi tratado como requisito no desenho das consultas.

  4. Repositórios como único acesso ao banco

    Só os arquivos *Repositorio.ts falam com o Firestore. Páginas e hooks nunca chamam o banco direto.

    Por quê: com o acesso concentrado, os testes com Vitest rodam contra um Firestore simulado em memória, sem depender de rede nem de emulador.