Ontem saiu o Node.js v18.15 com uma pancada de coisas legais e esse bug eu havia corrigido no 19 e finalmente ele veio para a versão LTS
Pra mim, essa é a prova de que quantidade de código não tem nada a ver com produção ou impacto
/2
Qual era o problema?
As Node.js Streams são parte do Node.js desde o início e muita coisa interna do Node.js as usa para controlar eventos e processar dados sob demanda
/3
Você pode usar as classes Readable, Writable e etc, para processar pentabytes de dados em JavaScript se precisar
O problema, é que elas trabalham com callbacks, então para ir para a forma mais moderna, há algum tempo é possível usar async generators.
/4
Algo como
async function *(stream) {
for await (const chunk of stream) {
// manipular pedaço de dados
}
}
E isso funcionava nas versões anteriores, mas por alguma razão no Node.js 19 (experimental) isso parou de funcionar 😬
/5
Consequentemente, isso quebrou todos os meus projetos 🥵
E se eu não tivesse resolvido, enquanto experimental, poderia ter quebrado centenas de milhares de pacotes que usam Node.js streams 😰😱
/6
Gastei alguns bons dias discutindo e depurando o projeto Node.js para entender o que poderia fazer até que finalmente entendi
/7
O negócio era que para fazer com que essas async generators funcionem, o modulo stream precisa ser carregado na inicialização da aplicação
Se você tentasse importar o método async pipeline, usado para controlar o fluxo de dados, como 'node:stream/promises'
/8
Ele na verdade, importava tudo que tinha dentro de "promises" e não carregava o módulo "stream"
Então, a linha única de código que fiz para solucionar o problema, foi no momento que carregasse "promises", também trouxesse o "stream"
/9
Uma linha de código que me tomou semanas para encontrar a solução e que sem ela poderia ter causado o CAOS 😂
/10
Só que não acaba ai, você precisa implementar testes para validar que o bug não existe mais, e aí gastei mais horas ainda para descobrir como faria esse teste
/11
Isso porque, a suite de testes do Node.js já carrega o modulo stream na inicialização, então precisei burlar o linter e dar uma "hackeada" na parada para funcionar
I've been creating videos on my youtube channel that you rarely will see in another place on the internet 🤩
You'll find there subjects like Recreating @nodejs from scratch, Web APIs and recreating web protocols such as the Web Socket using JS with no frameworks, etc
/2
And others, which are amazing experiments, such as recreating a code coverage tool from scratch and how to process terabytes of data using JavaScript
If you search about those subjects you'd reach out to my videos but why not have them as blog posts as well?
/3
Estava produzindo uma super aula do meu curso de Node.js Streams (em inglês), ensinando sobre como paralelizar o processamento de arquivos usando Node.js
A ideia é subir um processo para cada arquivo, e cada processo filtra os usuários que possuem o email em dominio gmail
/2
Só que eu automatizei a validação para verificar que todos os itens foram processados e enviados para um arquivo de saida
Então primeiro fui lá e usei o `grep` para filtrar o texto do arquivo e o `wc -l`, para obter a quantidade de linhas.
/3
The secret for processing anything using JavaScript is to handle data on demand.
Imagine data you wanna migrate data from a SQL database to a NoSQL DB. You would need to apply some business rules, clean up fields, filter data and then output them to the final output.
/2
You might know that you can block the Node.js (and the data source you're consuming) if you handle too much data at once in memory
The best practice then is to limit results, send individual data to a stream pipeline, and then ask for more data until you've consumed it all.
/3