Engineering

O fio condutor do meu trabalho não é uma linguagem. É a preferência por sistemas explícitos: comportamento local, falha limitada, storage recuperável e arquitetura que diz onde cada responsabilidade mora.

Princípios

Local-first é promessa operacional

Local-first não é "sincroniza depois" como remendo. IDs, locks, paths, checks de update e fluxos de usuário precisam ter comportamento razoável quando a rede não está disponível.

Segurança deve falhar fechada

Secrets devem ser referências, não payload em manifest. Paths devem ser canonicalizados. Bypasses de desenvolvimento não devem compilar em produção. Logs devem redigir valores com forma de segredo.

Arquitetura é fronteira de compatibilidade

AppCore separa application manifest, deployment manifest e runtime manifest porque ownership importa. Em Traiteur, a intenção do frontend também não é autoridade para segurança de filesystem local.

Performance antes da abstração

A ideia não é evitar abstração. É evitar abstração antes de entender escritas, locks, memória, custo de startup, volume de IO, recuperação e o workflow real do operador.

Trade-offs precisam de nome

AppCore não entrega RAFT, OAuth, database engine genérico ou workflow engine. Traiteur mantém referência curta para leitura humana, mas nunca a usa como identidade técnica.

Testes protegem contratos

Os testes importantes protegem fronteiras: manifests, segurança de path, totais de devis, ownership de lock, assinaturas de update, pacotes de storage e consumo do SDK público.

Como isso aparece no código

  1. Definir primeiro a fronteira de ownership.
  2. Separar infraestrutura e vocabulário de negócio por módulos ou repositórios.
  3. Versionar formatos de arquivo e rejeitar inputs não suportados sem adivinhar.
  4. Usar escrita atômica em storage crítico: temporário, flush, sync, rename e sync do diretório pai quando a plataforma permite.
  5. Preferir IDs determinísticos a contadores globais quando criação offline importa.
  6. Criar ferramentas operacionais: doctor commands, gates de release, diagnósticos, scripts de recuperação e documentação que um operador consiga seguir.

Mapa simples

Application code
  -> public facade / commands / queries
  -> runtime contracts
  -> storage, security, sync, scheduler, ops
  -> providers and host composition

O importante não é o formato do diagrama. É a direção do conhecimento: código de negócio pode pedir infraestrutura, mas infraestrutura não deveria aprender o vocabulário de um cliente.

Próxima leitura

Daniel Netto Logo2026 © Daniel Netto. Todos os direitos reservados.
Hospedado por Verceldnetto.dev