DEV Community: João Victor

Engenharia de Plataforma - Como justificar

João Victor — Wed, 17 Jun 2026 22:33:38 +0000

Baseado no livro "Engenharia de Plataforma", de Camille Fournier e Ian Nowland.

O paradoxo moderno

Nos últimos anos ficou absurdamente fácil construir software.
Com poucos cliques conseguimos provisionar:

Bancos de dados
Filas
Armazenamento
Sistemas de observabilidade
Serviços de autenticação

A maior parte dessas capacidades já existe pronta através de provedores de nuvem e ferramentas open source.

Porém, essa facilidade também trouxe uma certa fragilidade quando o assunto é manutenção. Na prática, muitas organizações acabam entrando no que Camille Fournier e Ian Nowland chamam de Pântano Generalizado (Muddy Middle): criar é fácil, evoluir é caro.

O problema não são os primitivos

Serviços como:

KMS
S3
Lambda
RDS
Kafka

não são o problema. Criam alavancagem e nos permitem nos preocupar somente com o necessário para a construção do produto.
Porém, cada vez que um time precisa utilizar um desses serviços, ele escreve um pouco de código para conectar sua aplicação ao serviço. Chamamos isso de cola.

A cola é inevitável. O problema está em não controlá-la!

A multiplicação da cola

Imagine uma empresa com vinte aplicações.

Todas precisam criptografar dados utilizando KMS.
Uma abordagem comum é:

Aplicação A → Helper próprio → KMS
Aplicação B → Helper próprio → KMS
Aplicação C → Helper próprio → KMS

Inicialmente parece uma ótima solução.
Cada equipe resolve seu problema rapidamente.

Meses depois surgem novos requisitos:

Rotação de chaves
Novo padrão de logs
Novo contrato de auditoria
Mudança de permissões

Agora existem vinte implementações diferentes para atualizar. O trabalho aumentou. Vamos tirar um bom tempo de algumas sprints para conseguir migrar totalmente essa cola dos projetos.

Centralizar a cola

Uma alternativa é transformar esse conhecimento em um ativo compartilhado.

Aplicação A ─┐
Aplicação B ─┼─> Crypto SDK → KMS
Aplicação C ─┘

Agora temos somente um ponto de cola. Quem desenvolve nossos aplicativos simplesmente não interage diretamente com o KMS.
Ao corrigir um bug, somente uma sprint é impactada, o lead time permanece pequeno e o WIP se mantém estabilizado, até mesmo em cenários de crise.

Nem tudo precisa ser uma feature

Gosto de partir de uma premissa simples:

Tudo que não tenha relação direta com a feature do produto

deveria ser chato, repetitivo e centralizado.
Alguns exemplos:

Logs
Observabilidade
Criptografia
Feature Flags
Autenticação
Pipelines
Governança de repositórios

Nenhum desses componentes gera diferencial competitivo para a empresa. O valor está em executá-los de forma consistente. É nisso que a companhia ganha.

Governança também é cola

Esse mesmo raciocínio aparece fora do código.
Um exemplo clássico é a criação de repositórios. Em muitas empresas, o processo acontece assim:

Repositório criado manualmente
Permissões configuradas manualmente
Pipelines configuradas manualmente
Scripts adicionados manualmente Cada novo projeto se torna uma nova oportunidade para inconsistências.

Com o tempo surgem perguntas simples que ninguém consegue responder:

Quem possui acesso?
Qual padrão de pipeline está sendo utilizado?
Quais verificações são obrigatórias?
Quais repositórios estão fora do padrão?

Não existe nenhum problema na stack ou na solução em si, e sim na cola espalhada por todos os serviços da companhia.

Engenharia de Plataforma como alavancagem

A plataforma interna não existe para esconder a tecnologia. Ela existe para centralizar e filtrar ruídos.

O desenvolvedor da solução não deveria pensar em como a empresa lida com logs, mas sim naquela solução específica. Ele deve ter um ambiente seguro e produtivo para se preocupar o máximo possível com a entrega de inovação.

A Engenharia de Plataforma permite que um pequeno grupo de engenheiros consiga reduzir o trabalho de toda uma companhia, convertendo tempo de troubleshooting de ferramentas em entrega de valor para o produto.

Entender seus colaboradores e equipes como clientes

A plataforma deve ter como foco oferecer uma alternativa melhor para o usuário. Não deveria ser mais complexo utilizar a abstração corporativa de logs ou de criptografia.

Utilizar essas abstrações deve ser melhor e mais fácil do que usar diretamente a biblioteca do KMS, por exemplo.

Conclusão

O estudo sobre plataformas internas está sendo muito interessante e estou aprendendo muito sobre como grandes players conseguem manter serviços consistentes, mesmo em um momento de tantas novidades.

Além disso, esse tema me parece extremamente importante no cenário atual, onde código virou commodity e estamos cada vez mais enfrentando dificuldades para manter a qualidade diante de um volume tão grande de informação.

Uma plataforma focada e bem planejada, com abertura para inovações, me parece uma das melhores formas de gerar software corporativo de verdade na era da IA.

Sem plataforma, existe ruído.

E uma coisa que escala rapidamente é o ruído e dívida técnica.

Event Loop - Entendendo uma das bases do Node

João Victor — Wed, 17 Jun 2026 21:51:46 +0000

O Event Loop é o mecanismo responsável por decidir quando callbacks e continuidades de operações assíncronas devem ser executados. Ele não executa operações de I/O diretamente, mas organiza a ordem em que elas retornam para o JavaScript. Essa arquitetura permite que o Node.js mantenha uma única thread de execução para JavaScript, enquanto delega operações de rede, disco e sistema operacional para componentes especializados do runtime e do próprio sistema operacional.

Início

Quando iniciamos um processo Node.js, o runtime carrega o arquivo de entrada da aplicação e executa todo o código síncrono disponível na Call Stack. Somente após essa etapa o Event Loop passa a assumir o controle do fluxo da aplicação, verificando continuamente quais callbacks estão prontos para execução.

   │           timers          │
   └─────────────┬─────────────┘
                 │
                 v
   ┌───────────────────────────┐
┌─>│     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │      close callbacks      │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤           timers          │
   └───────────────────────────┘

Trecho retirado da documentação principal.

Sobre o Event Loop

Durante muito tempo tratei o Event Loop como um dos conceitos mais complexos do Node.js. Depois de estudar a documentação oficial com mais calma, percebi que a dificuldade não está no Event Loop em si, mas na quantidade de conceitos diferentes que normalmente são apresentados ao mesmo tempo: libuv, Call Stack, Promises, Microtasks, Sistema Operacional e I/O.
Quando isolamos o papel do Event Loop, ele se torna surpreendentemente simples.

Definindo os passos e apresentando o iceberg 🧊

O Event Loop não executa trabalho. Ele agenda trabalho.

Acredito que o principal problema para entender o Event Loop esteja na confusão entre os contextos. Em um primeiro momento, imaginamos que o Event Loop é o "MacGyver" do runtime ou algo extremamente complexo. Porém, não é.

O interessante na arquitetura do runtime é como cada parte é extremamente especializada. Quando falamos de Event Loop, estamos falando única e simplesmente sobre quando executar um callback.

Pense no seguinte: a execução do JavaScript ocorre em uma única thread. Isso significa que os comandos vão rodar de forma linear, um após o outro, obrigatoriamente. Portanto, precisamos de algum mecanismo de coordenação para que o runtime seja minimamente confiável e siga um fluxo previsível.

Outro ponto extremamente importante: quando ouvimos falar em Call Stack, Microtasks e Event Loop, devemos entender que o Event Loop não possui uma Call Stack própria. Além disso, uma microtask tem muito mais relação com a Call Stack do que com o próprio Event Loop.

Se o assunto é Event Loop, podemos defini-lo como uma lista de prioridades para callbacks de naturezas diferentes. Isso explica o que ele faz, mas não explica como.

O Event Loop é um consumidor

Imagine o seguinte: o Event Loop tem como função depositar na Call Stack todos os callbacks que estão na fila da fase atual. Pense em cada fase como uma fila e no Event Loop como um consumidor.
Ele percorre obrigatoriamente as seguintes fases:

Timers
Pending Callbacks
Idle
Prepare
Poll
Check
Close Callbacks

Assim que você executa um código com Node.js, o fluxo ocorre da seguinte forma:

O Event Loop seleciona callbacks da fase atual e os coloca na Call Stack para execução.
A Call Stack executa um callback e, ao final da execução, drena a fila de microtasks. É aqui que entram as Promises resolvidas e as continuações geradas por async/await.
Após limpar a fila de microtasks, o runtime avança para a próxima fase do Event Loop.
O processo se repete até o encerramento da aplicação. Note que uma fase não possui necessariamente uma Call Stack própria. O runtime possui apenas uma Call Stack e uma fila de microtasks. As fases do Event Loop existem para determinar quais callbacks podem ser executados em cada momento.

Nem todas as fases são para você

Apesar de o diagrama do Event Loop apresentar sete fases, nem todas existem para que desenvolvedores JavaScript agendem callbacks diretamente.
Algumas fases são utilizadas internamente pela libuv para preparação e coordenação do runtime. Na prática, como desenvolvedor Node.js, você interage principalmente com Timers, Pending Callbacks, Poll, Check e Close Callbacks.

As fases Idle e Prepare, por exemplo, existem para permitir que a libuv realize atividades internas antes de entrar na fase de processamento de eventos. Embora façam parte do ciclo do Event Loop, dificilmente você terá contato direto com elas durante o desenvolvimento de aplicações.

Timers

Responsável por executar callbacks agendados por temporizadores.
Exemplos:

setTimeout(() => {
  console.log('Executado após 1 segundo');
}, 1000);
setInterval(() => {
  console.log('Executado periodicamente');
}, 5000);

Importante: o tempo informado representa o tempo mínimo de espera. Não existe garantia de execução exata naquele instante.

Pending Callbacks

Executa callbacks de determinadas operações que foram adiadas para a próxima iteração do Event Loop.
Essa fase é pouco utilizada diretamente por desenvolvedores, mas é frequentemente utilizada internamente pelo Node.js para reportar erros ou resultados de operações assíncronas.
Exemplo conceitual:

socket.on('error', (err) => {
  console.log(err);
});

Alguns callbacks relacionados a erros de rede e TCP podem passar por essa fase antes de serem executados.

Idle e Prepare

As fases Idle e Prepare são utilizadas internamente pela libuv para coordenar o funcionamento do runtime antes da entrada na fase Poll.
Durante essas etapas, a libuv realiza verificações, preparações e atividades de manutenção necessárias para o funcionamento correto do Event Loop. Apesar de fazerem parte oficialmente do ciclo, elas não possuem APIs públicas para que desenvolvedores registrem callbacks diretamente.
Exemplos
Não existem APIs JavaScript que permitam agendar callbacks para essas fases.

// Não existe algo equivalente a isso

idle(() => {});
prepare(() => {});

Quando utilizar
Nunca diretamente.
Como desenvolvedor Node.js, você normalmente interage apenas com as fases:

Timers
Pending Callbacks
Poll
Check
Close Callbacks #### Poll É a fase mais importante do Event Loop. Aqui a libuv verifica se existem operações de I/O concluídas e callbacks aguardando execução. Exemplos:

fs.readFile('arquivo.txt', (err, data) => {
  console.log(data.toString());
});
http.createServer((req, res) => {
  res.end('Olá');
});
database.query('SELECT * FROM users', callback);

Leitura de arquivos, conexões de rede, requisições HTTP e diversas operações assíncronas costumam retornar seus callbacks para esta fase.

Check

Executada logo após a fase Poll.
É a fase utilizada pelo setImmediate().
Exemplo:

setImmediate(() => {
  console.log('Executado na fase Check');
});

Uma forma simples de pensar é:

setTimeout(..., 0) → Timers
setImmediate(...) → Check

Close Callbacks

Executa callbacks relacionados ao encerramento de recursos.
Exemplo:

socket.on('close', () => {
  console.log('Conexão encerrada');
});
stream.on('close', () => {
  console.log('Stream finalizada');
});

Essa fase permite que recursos sejam liberados corretamente antes do término definitivo da operação.

Conclusão

O assustador Event Loop é, na prática, apenas um coordenador das nossas invocações. Toda a parte pesada acontece entre o kernel do sistema operacional e a libuv.

WIP - Glossário DevOps #1

João Victor — Wed, 17 Jun 2026 21:36:10 +0000

Texto com base no livro "Manual de DevOps"

WIP significa "Work In Progress". É uma métrica essencial que representa a quantidade de trabalho iniciado, mas ainda não concluído.
Na prática, ela ajuda a entender quantos tickets, tarefas, histórias ou demandas estão sendo executados simultaneamente pelo time.

WIP Alto (Ruim)

Time com 5 pessoas
20 histórias abertas
Todos pegam várias tarefas ao mesmo tempo
Dezenas de branches simultâneas
Dezenas de PRs simultâneos

WIP Baixo (Bom)

Time com 5 pessoas
Apenas 5 histórias abertas
Cada pessoa trabalhando em uma tarefa por vez
O time termina as tarefas antes de começar outras
Menor Lead Time

Essa métrica é essencial para uma boa estratégia de DevOps, além de ser um baita indicador para a saúde do projeto ou da companhia.

Quanto maior o WIP:

Maior troca de contexto
Mais conflitos de merge
Mais difícil rastrear e validar as entregas
Maior "latência" no tempo de aprovação dos PRs Se seu time está começando muitas frentes e terminando poucas demandas, você está com um WIP alto, e isso afeta diretamente a qualidade das entregas e a qualidade de vida das pessoas.

Sei que WIP aparece bastante nos princípios Lean, porém ainda não li o suficiente sobre o tema para me aprofundar nele.

Melhorando seus testes com Jest

João Victor — Mon, 10 Jan 2022 21:26:01 +0000

Nesse artigo explicarei sobre como tornar nossos testes mais performaticos e sólidos.

Introdução

Olá, me chamo João e me encontrei com um grande problema. Estava desenvolvendo um projeto no qual consumia uma API, para ser mais exato, está API era disponibilizada pela rapidApi. Como sou um mero mortal(e estudante), estava utilizando do plano gratuito. Contudo, esse disponibiliza apenas 500 requests por mês. Sério, consegui estourar esse limite em um dia kkkkk.Seria impossivel desenvolver o app com tantas poucas requisições.
Graças a esse "aperto", pensei em desenvolvelo utilizando de TDD(Test Driven Development), que é basicamente desenvolver guiados por teste. Nesse artigo irei mostrar o porquê. Espero que goste e que acima de tudo, te ajude!😁

Preparando o ambiente

Para recriar o ambiente no qual estava, criarei uma API super simples com Express, utilizarei do Axios para fazer as requisições e claro, faremos os testes com o Jest.

Expres, um pouco de arroz e feijão

A api ficou bem simples. Basicamente criei uma rota que recebe um query e retorna um JSON. Além disso fiz uma função sleep para simular uma latência.

Configurando app para consumir nossa API

Aqui criaremos o projeto, nele utilizaremos além dos jest para testes, usaremos também o babel para termos uma sintaxe um pouco mais agradável.(Deixarei o repositório no final do artigo, não se preocupe!)
A estrutura do projeto ficou assim:

Pasta __teste__:

Evidentemente, será nela onde ficara nossos testes.
Pasta utils:

Nela ficara nossa instância no Axios, segue o código:

Jest, e TDD

Agora iremos produzir nosso teste para a função. Em TDD primeiro fazemos os testes e só depois a função.

Esqueleto da função

Basicamente, iremos apenas declarar a função para podermos importa-la nos testes.

Agora sim partiremos para os testes. Temos de pensar no que a função vai fazer. Nesse caso, ela deve receber um nome, e retornar um objeto tipo: { message: 'Olá, teste' }.

Esse é basicamente nosso teste. A primeiro momento ele irá falhar(ainda bem). A partir de agora temos que fazê-lo passar.

Para isso, implementei nossa função, ela ficou da seguinte forma:

O teste ainda não vai passar, já que como essa é uma função async e recebemos apenas uma promise.

Aprovando o teste

Agora, vamos tratar o retorno da função sendHelloWorld lá nos nossos testes. Isso significa que temos apenas que botar um async na função e utilizar um await no retorno da função. Ficou assim:

Pronto, nossa função passou! Porém, existe um pequeno problema. Com o tempo, nossos testes podem acabar crescendo em quantidade, além disso. Estamos dependendo de uma API externa para executarmos o código. Isso tornam eles menos confiáveis, além de que podem ser extremamente voláteis. imagina se a latência fique alta? Não seria mais inteligente interceptarmos a request que fizemos ao servidor e retornar um valor pré determinado? um Mock? Bom, eu acredito que sim.

Não dependa de API's nos testes.

Estamos na parte final do nosso artigo. porém, a mais importante. Imagine um cenário no qual temos 10 testes onde cada um deles faz uma request para algum serviço externo ou API. Nossos testes estariam diretamente ligados a algo no qual não temos o minimo controle. Eles poderiam demorar 3s ou até mesmo 20s, tudo dependeria da latência. Para evitarmos tal problema, o Jest tem uma forma bem simples. Podemos reescrever certas funções, olha que interessante!(me pareceu magia quando descobri kkkk).

Reescrevendo métodos

Bom, agora que ja entendemos oque fazer, temos que realmente fazer. Olha o quão simples é reescrever uma função no jest:

Pronto, agora temos um teste totalmente isolado, isso é incrivel!!

Conclusões

Espero que tenha aprendido um pouco mais sobre TDD e entendido o quanto foi util pra mim essa alternativa. Além disso, irei passar aqui alguns links que me ajudaram a escrever o artigo e descobrir essa solução:

Repositório com o exemplo

Github

DEV Community: João Victor

Engenharia de Plataforma - Como justificar

O paradoxo moderno

O problema não são os primitivos

A multiplicação da cola

Centralizar a cola

Nem tudo precisa ser uma feature

Governança também é cola

Engenharia de Plataforma como alavancagem

Entender seus colaboradores e equipes como clientes

Conclusão

Event Loop - Entendendo uma das bases do Node

Início

Sobre o Event Loop

Definindo os passos e apresentando o iceberg 🧊

O Event Loop é um consumidor

Nem todas as fases são para você

Timers

Pending Callbacks

Idle e Prepare

Check

Close Callbacks

Conclusão

WIP - Glossário DevOps #1

WIP Alto (Ruim)

WIP Baixo (Bom)

Melhorando seus testes com Jest

Introdução

Preparando o ambiente

Expres, um pouco de arroz e feijão

Configurando app para consumir nossa API

Jest, e TDD

Esqueleto da função

Aprovando o teste

Não dependa de API's nos testes.

Reescrevendo métodos

Conclusões

Repositório com o exemplo