Em 19 de junho de 2025, fui ao PiterJS #79 em São Petersburgo. A noite teve um tema pouco glamouroso, e justamente por isso interessante: não como entregar a próxima feature, mas como manter o que já foi construído — monitoramento, deployment e refactoring.
A programação combinava bem com esse tema. Pavel Shlykov falou sobre melhorar um monólito antigo, Alexander Panfilov abordou FrontOps e Igor Antonov falou sobre métricas de performance de aplicações web. Saí com anotações práticas sobre os três assuntos.
A parte inesperada foi o Q&A. Acabei ganhando dois prêmios pelas melhores perguntas durante as sessões. É um detalhe pequeno, mas se tornou a lembrança mais marcante da noite porque reforçou por que ainda valorizo meetups técnicos presenciais: dá para fazer mais do que consumir uma palestra pronta. Você pode testar seu entendimento enquanto as pessoas que acabaram de apresentar o assunto ainda estão na sala.
O tema útil era manutenção, não novidade
Eventos de frontend podem facilmente virar um desfile de frameworks, APIs e abstrações novas. O PiterJS #79 foi mais pé no chão. O tema anunciado era dar suporte ao software que já existe.
Isso importa porque grande parte do trabalho de engenharia começa depois do primeiro release bem-sucedido. Um monólito legado não é automaticamente um sistema ruim, e “modernização” não significa automaticamente reescrever tudo. A pergunta prática costuma ser mais específica: qual limitação está causando problemas agora e qual mudança reduz esse problema sem criar mais risco do que elimina?
Também foi por isso que as três palestras funcionaram bem juntas. Refactoring muda o código. FrontOps muda como o frontend é construído, empacotado, entregue e operado. O trabalho de performance muda como medimos o resultado. São camadas diferentes do mesmo problema: manter um sistema real compreensível e controlável depois que ele cresce.
FrontOps é mais amplo do que um Dockerfile
Uma das minhas anotações do meetup era sobre implementar FrontOps com Docker. A distinção importante é que Docker é uma ferramenta, não a definição de FrontOps.
A responsabilidade pelo frontend não termina necessariamente quando npm run build conclui com sucesso. Em produção, alguém ainda precisa pensar em builds reproduzíveis, empacotamento de artefatos, configuração, rollback de releases, comportamento de cache e observabilidade de falhas. Containers podem tornar parte desse trabalho mais previsível, mas não substituem as decisões operacionais.
Essa é uma correção útil para um modelo mental comum: um build bem-sucedido prova que o build terminou. Não prova que a aplicação será implantada corretamente, que vai se comportar corretamente em produção nem que será fácil recuperá-la quando algo der errado.
Performance começa definindo o que significa “lento”
A palestra sobre performance foi especialmente prática na forma de enquadrar medição. O escopo anunciado incluía fatores que afetam a velocidade de carregamento, diferentes métricas de performance frontend, formas de quantificar o que é “lento” e até a pergunta sobre por que otimização nem sempre é necessária.
Esse último ponto é fácil de subestimar. “Deixe mais rápido” parece um objetivo, mas sem uma métrica e sem um problema visível para o usuário pode virar adivinhação cara. Um processo útil de performance começa definindo o que de fato está lento, medindo, identificando o gargalo, alterando algo relevante e medindo novamente.
Uma métrica não é, por si só, a experiência do usuário, mas dá à discussão uma unidade comum. Sem medição, o trabalho de performance pode virar uma coleção de mudanças tecnicamente impressionantes sem evidência clara de que resolveram o problema que realmente importava.
O Q&A mudou o valor do meetup para mim
Eu poderia ter assistido às gravações e guardado links depois. O que seria mais difícil reproduzir é a interação em torno das palestras. Fazer uma boa pergunta obriga você a condensar uma incerteza em algo específico o suficiente para outro engenheiro responder.
Ganhar dois prêmios foi divertido, mas a lição mais útil foi mais simples: chegar preparado para participar dá muito mais valor a um meetup presencial do que tratá-lo como uma playlist do YouTube ao vivo.
Uma boa pergunta técnica normalmente inclui contexto e uma restrição. Em vez de “Qual é a melhor arquitetura?”, pode ser mais útil perguntar qual trade-off muda quando uma equipe não pode reescrever um sistema legado, quando o deployment precisa continuar retrocompatível ou quando uma métrica melhora sem um benefício correspondente perceptível pelo usuário.
Isso não significa que toda pergunta precise ser brilhante. Significa que ela deve ajudar a expor suposições, limites ou modos de falha.
O que eu levaria para o próximo meetup técnico
- Saber por que uma palestra importa para mim. Anotar antes do início um problema real ou uma dúvida relacionada ao tema.
- Separar a experiência do palestrante do meu próprio sistema. Um bom estudo de caso é evidência, não uma receita universal.
- Perguntar sobre trade-offs. “Quando você não usaria isso?” muitas vezes revela mais do que “Qual ferramenta é a melhor?”
- Registrar uma ação de acompanhamento. Uma anotação é mais útil quando aponta para algo que eu possa verificar, testar ou ler depois do meetup.
- Não confundir uma palestra convincente com prova em produção. Decisões de arquitetura, deployment e performance ainda precisam ser validadas no próprio ambiente.
O que ficou comigo
Não quero exagerar o quanto um único meetup pode mudar. Não saí do PiterJS com uma receita universal de arquitetura, e uma boa palestra não substitui documentação, profiling, testes ou dados de produção.
O que eu realmente levei foi mais concreto: anotações úteis sobre modernização de um monólito legado, FrontOps com Docker e medição de performance web; dois prêmios no Q&A; e mais um lembrete de que vale a pena aparecer pessoalmente nas comunidades locais de desenvolvedores.
Gravações podem preservar a apresentação. A parte mais difícil de arquivar é a conversa ao redor dela.