devfrs — Notas técnicas

O que eu construo, e por que escrevo sobre isso

Fri, 31 Jul 2026 13:00:00 GMT

Este blog existe por um motivo prático: eu esqueço.

Não o que fiz — o porquê. Seis meses depois de uma decisão de arquitetura o código continua lá, mas a razão evaporou. Sobram as consequências sem o argumento, e ninguém consegue revisar uma decisão que não sabe reconstruir. Escrever é a forma mais barata que encontrei de deixar o argumento junto com o resultado.

O segundo motivo é menos nobre e igualmente verdadeiro: explicar por escrito revela na hora se eu entendi. Quase todo texto que comecei aqui mudou de conclusão no meio, porque a versão que estava na minha cabeça não sobreviveu a ser dita em voz alta.

Onde eu trabalho

Sou desenvolvedor no Grupo Coagro desde julho de 2024. O trabalho lá é estender um ERP que continua sendo o ERP: mapear onde a regra dele termina e construir só a borda em que o negócio pede uma regra que ele não tem. CRM de campo, emissão de receita agronômica, acesso único. Escrevi sobre isso em Onde o ERP termina.

Fora do horário, pego projeto freelance de web e mobile. Não é vida dupla: é o mesmo problema em escalas diferentes — alguém precisa de software que funcione e de alguém que responda por ele.

A stack, e por que é essa

Lista de tecnologia não diz nada sobre ninguém. O que diz é o motivo de cada escolha.

Flutter é onde passo a maior parte do tempo. A razão não é a linguagem: é que time pequeno não sustenta duas bases nativas, e a alternativa honesta ao multiplataforma quase sempre é atender bem uma plataforma e mal a outra. Quando o app roda na mão de quem está em campo, com conexão ruim, o que importa é ele existir nos dois lugares e responder rápido.

React e Electron para o que vive no navegador e no desktop. Electron tem má fama merecida por peso, e ainda assim continua sendo a resposta certa quando o requisito é acesso ao sistema de arquivos com a mesma interface do web.

Supabase pela modelagem, não pelo atalho. O que ele resolve bem é entregar Postgres de verdade com RLS na frente — regra de acesso que mora no banco, não na aplicação. Regra de acesso em código de aplicação é regra que alguém esquece de aplicar em algum caminho.

Docker e Kubernetes para o que precisa subir igual em qualquer máquina. A parte que interessa não é o contêiner: é “funciona na minha máquina” deixar de ser uma frase possível.

CI/CD com GitHub Actions — e o hábito que mais mudou meu dia: rodar o pipeline localmente, no terminal, antes do push. Pipeline que só roda no servidor transforma cada erro de lint num ciclo de commit, push e espera. Rodando antes, o erro custa segundos e nunca vira ruído no histórico.

O que eu construo fora do trabalho

App de academia. A parte visível é registro de treino; a parte difícil é a modelagem. Carga, série, repetição e progressão parecem quatro campos até você tentar responder “esta pessoa está evoluindo?” — aí viram histórico, comparação entre períodos e a diferença entre trocar de exercício e trocar de estímulo. É o tipo de problema em que errar o esquema cedo compra uma migração feia depois.

Integrações via API com plataformas grandes, como Dropbox e Google Maps. Integração é sempre a mesma lição com roupa nova: o contrato é de outra pessoa, muda sem avisar, e falha de rede não é exceção — é estado normal que o código precisa saber tratar.

SaaS e ferramentas com IA. Ainda em exploração, e a pergunta que carrego é onde o modelo agrega de fato e onde ele só acrescenta uma fonte de erro plausível. Resposta plausível e errada é o defeito mais caro que existe, porque ninguém confere o que não pareceu estranho.

O que vem aqui

Decisão de arquitetura com o argumento junto. Erro que me custou tempo, contado com o número que me fez perceber. Solução que procurei e não achei escrita em lugar nenhum.

Não pretendo escrever tutorial de coisa que já tem documentação boa. Pretendo escrever o que eu teria gostado de encontrar às duas da manhã.

Onde o ERP termina: estendendo o Winthor na Coagro

Fri, 31 Jul 2026 11:00:00 GMT

O Winthor é o ERP do Grupo Coagro e vai continuar sendo. Estoque, faturamento, tabela de preço, cadastro, título a receber: está tudo lá, funciona, e ninguém no time quer mexer nisso.

Por isso a pergunta que interessa nunca foi “trocar ou manter”. É outra, mais estreita e bem mais útil:

Onde a regra do ERP termina e a regra do negócio continua?

Um ERP de distribuição é projetado para o caso geral — o que vale igualmente para quem vende parafuso, medicamento ou defensivo agrícola. É isso que o torna confiável ao longo de vinte anos, e é exatamente isso que deixa bordas: a parte do negócio que não é “distribuição genérica” não tem por que estar lá dentro.

O trabalho mora nessas bordas. Não substituir o que o Winthor faz — acrescentar a regra que ele não teria motivo para ter.

Três lugares onde a borda aparece

O pedido existe. A conversa que leva até ele, não.

O ERP registra pedido. Mas pedido é o fim de uma sequência: visita à propriedade, diagnóstico da lavoura, recomendação, proposta, negociação, retorno. Nada disso é venda ainda, e por isso nada disso cabia no lugar onde a venda mora.

Sem lugar, essa sequência ficava na cabeça do vendedor e no caderno dele. Funciona — enquanto ele está lá. No dia em que ele sai de férias, a carteira sai junto.

O CRM cobre esse trecho, e só ele. Lê do Winthor o que já é verdade (cliente, histórico de compra, limite de crédito, produto disponível) e guarda o que ainda não virou pedido. Quando vira, o pedido nasce no ERP, onde sempre nasceu.

Feito em Flutter porque vendedor de insumo trabalha na fazenda, não na mesa. Um CRM que só abre no desktop vira preenchimento noturno, de memória — quando é preenchido.

Receita agronômica é documento legal, não formulário

Emitir receita agronômica é um ato com responsabilidade técnica: produto, cultura, alvo, dose, área, responsável e assinatura, dentro do que a legislação permite para aquela combinação. Não é um campo de texto — é uma regra que valida antes de imprimir.

Esse é o tipo de regra que um ERP de distribuição não tem por que carregar: ela não vale para quem vende parafuso. Vale para nós, e errar nela não é retrabalho, é risco regulatório.

A ferramenta puxa do ERP o que já existe — produto, cliente, o que foi comprado — e aplica em cima a regra que o ERP não conhece. O agrônomo para de digitar o que o sistema já sabe e volta a decidir o que só ele pode decidir.

“Lembrar de todos os sistemas” não é controle de acesso

Cada ferramenta nova nasce com uma pergunta chata: quem entra? Resolvida ferramenta a ferramenta, a resposta vira um login por sistema — e desligar alguém passa a depender de lembrar de todos eles.

Lembrar não é um controle. É uma intenção.

Centralizar o acesso não foi conforto de quem usa. É a diferença entre revogar um acesso e torcer para ter revogado — e, numa empresa que movimenta crédito e dado de cliente, essa diferença tem nome: auditoria.

O princípio que segurou tudo

Olhando os três casos lado a lado, o padrão é o mesmo:

O dado é do ERP. A regra nova é nossa. E a regra nunca copia o dado.

Se a informação já tem dono no Winthor, ela é consultada, não replicada. Duplicar é mais rápido de escrever e mais barato de ler — e é exatamente por isso que é tentador. A conta chega depois, no dia em que as duas cópias divergem e ninguém sabe qual está certa. Ninguém quer descobrir isso pelo cliente.

O que o Supabase guarda é só o que nasceu com as ferramentas e não existe no ERP: sessão, permissão, rascunho de visita, a anotação que ainda não virou pedido.

O que continua difícil

Ler de um banco que não é seu significa tratar o schema dele como uma API que você não controla — sem versionamento, sem changelog, sem deploy coordenado. Uma coluna que muda de significado não avisa; ela só passa a devolver outra coisa.

A defesa é a de sempre, e não é sofisticada: falhar alto. Integração que quebra em silêncio devolve um número plausível, e número plausível e errado é o defeito mais caro que existe — porque ninguém vai procurar o que não deu erro.

O que eu tiro disso

“Modernizar o ERP” quase nunca quer dizer trocar o ERP. Quer dizer mapear com precisão onde ele acerta — que costuma ser a maior parte — e construir só na borda em que o negócio pede uma regra que ele não tem.

O Winthor continua sendo a fonte da verdade. O que mudou é que ele deixou de precisar responder sozinho por perguntas que nunca foram dele.

O Lighthouse estava medindo a página errada

Thu, 30 Jul 2026 12:00:00 GMT

Eu estava endurecendo o gate de Lighthouse do devfrs.com: sair de warn e passar para error, com SEO em 100. O primeiro resultado veio estranho.

rota	perf	seo
`/`	75	100
`/en/`	38	100
`/projeto/<slug>/`	79	100

Trinta e oito. Em páginas praticamente idênticas, geradas pelo mesmo build. E o SEO, que era o que eu estava mexendo, tinha chegado em 100 — então a tentação era comemorar e tratar a performance como ruído.

O sintoma que não fechava

Junto com os números veio uma reprovação em link-text: um link com o texto “Learn more” apontando para docs.astro.build. Eu não tenho esse link em lugar nenhum. Procurei no dist/ inteiro:

grep -r "docs.astro.build" dist/

Nada. O link não existia no que eu tinha construído — mas existia na página que o Lighthouse mediu. Só há uma explicação para isso: a página medida não era a minha.

A causa

Aquele “Learn more” é da barra de ferramentas do Astro, que só existe em modo dev. O que o Lighthouse auditou foi o dev server, não o dist/.

O motivo é bobo e é justamente por isso que passa despercebido: eu tinha um npm run dev aberto na porta 4321, e meu servidor de teste tentava subir na mesma porta. Ele falhava, o processo morria em silêncio, e o Lighthouse encontrava alguém respondendo em 4321. Mediu com prazer.

Perf 62 num site em dev é um número perfeitamente plausível. É esse o problema. Um erro que grita é barato; um erro que devolve um número crível custa horas.

As duas correções

A primeira é óbvia: porta separada para o gate. A segunda é a que importa:

server.on("error", (err) => {
  if (err.code === "EADDRINUSE") {
    console.error(
      `[serve-dist] porta ${PORT} já está em uso — abortando.\n` +
        `Outro processo responderia no lugar do dist/ e o Lighthouse mediria a página errada.`,
    );
  }
  process.exit(1);
});

Falhar alto em vez de baixo. Se a porta está ocupada, ninguém mede nada — melhor derrubar o gate com uma mensagem clara do que publicar um número inventado.

Com o servidor certo e mediana de três execuções, os números viraram 95 e 99. E aí sim dava para travar o gate.

O que eu tiro disso

Antes de acreditar numa medição, vale perguntar o que ela mediria se estivesse quebrada. Se a resposta for “um número parecido com o certo”, falta um sinal — não falta precisão.