Entenda o que são Buffers e qual o seu papel no Node.js

Também são utilizados quando estamos lendo arquivos com o fs.readFile().

Diferentemente de uma string, buffers são sequências de bytes puros que armazenam e acessam informações direto na memória.

Isso torna a leitura e escrita de dados extremamente rápida e eficiente comparando-os a strings tradicionais.

Como os Buffers funcionam?

Sendo os buffers bytes alocados estaticamente e com um tamanho fixo, caso uma alteração de tamanho seja necessária, também é necessário criar um novo buffer.

Em Node.js existem várias formas de criar buffers. Vamos ver algumas delas:

Buffer.alloc(tamanho)

Este método cria um buffer de tamanho específico, preenchido com zeros por padrão. É uma maneira segura de se criar um buffer, pois garantimos que a memória alocada esteja limpa.

Buffer.from(data)

Este método cria um buffer a partir de dados existentes, como uma string, um array ou outro buffer. Ele é amplamente utilizado para converter strings em buffers.

O método Buffer.from() também aceita arrays:

Caso deseje passar um objeto, é necessário primeiro transformá-lo em uma string:

Temos também o método Buffer.allocUnsafe(tamanho), ele é usado para criar um novo buffer de um determinado tamanho, porém, sem inicializar os seus dados. Isso significa que o buffer pode conter dados antigos ou sensíveis da memória:

Como o allocUnsafe pode trazer dados antigos da memória, para garantir a segurança dos dados, use o Buffer.alloc().

Caso queira garantir que os dados no allocUnsafe sejam zerados, você ainda poderá usar o método .fill(0)após criar o buffer:

O Buffer.allocUnsafe deve ser usado em casos extremamente específicos, como quando a performance for mais importante do que a segurança, se todos os bytes vão ser reescritos antes de serem usados, ou para otimizar buffers temporários dentro de sistemas de alto desempenho.

Não o utilize ao acaso, a não ser que o uso se justifique pela situação, sempre tenha preferência pelo Buffer.alloc() ou pelo Buffer.from().

Como o Buffer funciona internamente?

Podemos dizer que o Buffer no Node.js é essencialmente um wrapper em torno de um Uint8Array, que faz parte da API TypedArray do JavaScript.

Vamos entender melhor cada ponto dessa definição:

Um wrapper é um objeto que encapsula outra estrutura de dados ou funcionalidade, fornecendo uma interface adicional para facilitar seu uso.

O Buffer no Node.js é um wrapper pois encapsula um Uint8Array e adiciona métodos extras para manipular buffers de forma mais conveniente.

Uint8Array é um tipo específico de TypedArray no JavaScript, que representa uma sequência de números inteiros de 8 bits sem sinal (valores entre 0 e 255). Ele é eficiente para manipular dados binários, pois cada elemento ocupa exatamente 1 byte de memória.

Se você quiser se aprofundar no tema das Uint8Arrays, acesse este conteúdo no site do Mozilla. O texto está em inglês.

A API TypedArray é um conjunto de classes do JavaScript projetadas justamente para manipulação de dados binários e se difere dos arrays comuns do JavaScript por armazenarem valores diretamente na memória, com um tamanho fixo e sem sobrecarga de objetos JavaScript.

• Uint8Array → Inteiros sem sinal de 8 bits (valores de 0 a 255)
• Int8Array → Inteiros com sinal de 8 bits (valores de -128 a 127)
• Uint16Array → Inteiros sem sinal de 16 bits (0 a 65535)
• Float32Array → Números de ponto flutuante de 32 bits

Existem vários outros TypedArrays, caso tenha interesse você pode consultar todos os tipos no site da Mozilla. Em inglês.

E como o Buffer usa o Uint8Array?

Como dito anteriormente, o Buffer do Node.js é essencialmente um wrapper em torno de um Uint8Array. Ele usa Uint8Array internamente, mas adiciona métodos extras para facilitar a manipulação de dados binários.

Aqui vai uma comparação entre o Uint8Array e o Buffer

Embora ambos armazenem os mesmos dados, o Buffer adiciona funcionalidades e extras como .toString(), .copy(), .slice(), .write() entre outras funções.

Mas calma! Vamos ver algumas dessas funções na sequência.

Manipulação de Buffers

Escrever dados em um buffer

Para Buffers que já foram criados, podemos escrever utilizando o método .write()

Nesse caso, como ambas as palavras têm 5 letras não precisamos passar nenhum delimitador. Caso fosse necessário editar apenas um ou mais caracteres, a chamada do .write() precisaria ser alterada:

Concatenar dados usando buffers

Também é possível concatenar o conteúdo de dois buffers, gerando um novo que já comporta o tamanho dos dois outros utilizados como base:

Copiar conteúdo de um buffer para outro

Podemos copiar o conteúdo de um buffer, mas é importante lembrar que o tamanho do novo deve ser igual ou maior. Caso contrário, ele irá cortar os bytes que estão “sobrando”:

Essa regra também se aplica para a escrita: tentar escrever num buffer um conjunto de dados maior que o tamanho original dele causará um “corte” nos dados excedentes.

Alterar dados em um buffer

Também podemos alterar uma informação de forma mais precisa em um buffer passando sua posição no array.

O Buffer é basicamente um array de bytes. Assim, podemos criar um buffer a partir de uma string e modificar seus valores diretamente, acessando os índices como em um array normal.

Cada caractere da string inicial ocupa um byte no buffer. Quando acessamos buffer[0] = 77;, estamos alterando diretamente o primeiro byte.

O Buffer não se comporta como uma string imutável. Se alterarmos um índice específico, ele muda apenas esse byte, mantendo os outros inalterados.

Cuidados ao modificar um Buffer

Cada posição do Buffer representa um único byte (0-255). Se você definir um valor maior que 255, o Node.js aplicará um & 255, mantendo apenas os 8 bits menos significativos:

Quando lidamos com textos em UTF-8 (como caracteres acentuados), um caractere pode ocupar mais de um byte. Alterar um byte isolado pode corromper o texto:

Então para textos UTF-8, use Buffer.alloc() e evite alterar diretamente bytes individuais.

Importância dos Buffers em Streams

As streams são uma abstração para manipulação eficiente de dados de forma assíncrona. Buffers são cruciais para streams, pois permitem manipular fragmentos de dados que chegam aos poucos, sem precisar carregá-los completamente na memória.

Ao ler um arquivo grande, por exemplo, em vez de carregar tudo de uma vez, usamos streams que processam pequenos blocos de dados armazenados temporariamente em buffers. Isso reduz o consumo de memória e melhora a performance.

Exemplo de uso de Buffers em Streams

Para os exemplos que vem a seguir, eu criei um arquivo NDJSON que simula um relatório escolar, contendo algumas informações sobre o aluno e suas matérias.

Mas para esse primeiro exemplo você pode criar um simples arquivo.txt.

Caso deseje utilizar o mesmo arquivo que eu, copie o ndjson abaixo, crie um arquivo *.ndjson, cole e salve o novo conteúdo:

O código abaixo cria uma stream de leitura que vai ler nosso ndjson e retornar no console o seu conteúdo:

Saída:

O fs.createReadStream já fornece o uso de Buffers de maneira implícita, por isso console.log() nos dados do chunk imprime um Buffer como resposta no terminal e em seguida, ao usar o método .toString() conseguimos converter esse valor para uma string legível para nós, humanos.

No Node.js, o termo chunk se refere a um pedaço pequeno e gerenciável de dados que faz parte de um conjunto de dados maior.

Porém, temos um ponto interessante: como deixamos para o próprio Node.js lidar com o Buffer para essa leitura, ele criou um Buffer que corresponde ao tamanho total do arquivo.

Nosso arquivo tem apenas 3 linhas e 535 bytes, mas utilizamos streams para processar arquivos pequenos e principalmente arquivos grandes, no caso, 2GB ou maiores.

Então, caso nosso arquivo tivesse 2GB, o Buffer criado teria por volta dos 2.147.483.648 bytes. Essa quantidade de bytes seria consumida em nossa memória durante a execução da stream?

No caso da leitura do arquivo, a resposta é não!

Por padrão a fs.createReadStream tem uma propriedade chamada highWaterMark que vai dividir os chunks da leitura em um tamanho fixo de 64 KB (64 * 1024 bytes).

Quando estamos falando da escrita, a mesma regra se aplica? Bom, aí as coisas começam a ficar um pouco mais interessantes! Vamos para um exemplo mais prático para entender alguns conceitos.

Abra o seu gerenciador de tarefas e habilite o filtro para processos com o nome Student, ou mais precisamente StudentStreamsGenerator:

Agora vamos criar um script para gerar um relatório em formato `ndjson. Assim conseguiremos informações sobre nossos alunos de forma randômica, utilizando streams:

No caso, estamos criando um processo chamado StudentStreamsGenerator e criando um milhão (1_000_000) de registros de alunos.

Ao executar o nosso script e verificar o terminal, podemos ver um alto consumo de memória atrelado a esse processo:

Agora vamos criar um novo arquivo para ler nosso novo relatório:

Ao executar esse script, a execução é tão rápida que no nosso caso, não é possível ver o processo ser registrado no gerenciador de tarefas. Isso acontece porque o sistema operacional lê os dados de maneira extremamente rápida.

Os testes foram feitos em um computador Intel Core i7-12700H com 16GB de RAM.

Então, temos um resultado bem satisfatório usando streams para leitura de arquivos grandes, mas na hora de criar o relatório, por mais que o processo seja executado em alguns segundos (nesta situação, 8 segundos), temos um alto consumo de memória.

Qual o motivo desse comportamento?

Primeiramente, não temos um controle sobre o nosso fluxo de escrita e assim, geramos um problema de backpressure.

Ou seja, o writeStream.write() não espera que o chunk anterior seja completamente escrito no arquivo antes de adicionar um novo ao buffer interno.

Se o buffer interno do writeStream ficar cheio (ou seja, atingir o highWaterMark), o método write retorna false, indicando que a aplicação deve parar de escrever até que o evento drain seja emitido.

No caso, nossa aplicação não está emitindo o evento drain, logo o writeStreamentende que pode continuar adicionando chunks ao buffer interno e seguir escrevendo o que for necessário.

Quanto ao Backpressure, ele é o mecanismo que controla o fluxo de dados entre streams para evitar que o produtor (o loop que gera os estudantes) sobrecarregue o consumidor (writeStream).

Em nosso código o loop continua escrevendo estudantes sem verificar se o writeStream está pronto para receber mais dados. Como o loop não espera o writeStream processar os dados, os chunks se acumulam no buffer interno da stream, causando um consumo alto de memória.

Vamos então tentar uma solução que utilize esse controle de backpressure e só escreveremos se o buffer ainda tiver espaço para isso. Caso contrário, vamos esperar que o buffer interno seja esvaziado para poder voltar a escrever os dados de estudantes.

Resolvendo backpressure com recursão

Adaptando nossa aplicação:

Vamos entender um pouco os pontos chave para essa nova implementação, que faz uso de uma função recursiva para manter o fluxo de escrita.

Dentro da função principal generateStudentsWithStreams temos uma função chamada writeStudent. Como toda boa função recursiva, temos uma validação para definir a saída dessa nossa função.

Caso nosso contador seja maior ou igual ao número de estudantes que escrever, iremos fechar a stream e sair com um return:

Vamos para o próximo passo:

Geramos então um estudante e convertemos para uma string JSON. O método writeStream.write tenta escrever os dados no arquivo, retornando true se os dados forem adicionados ao buffer interno do writeStream e false se o buffer estiver cheio (ou seja, atingiu o highWaterMark).

Agora fazemos o controle do backpressure:

Se canContinue for true, o buffer interno do writeStream ainda terá espaço para mais dados e a função writeStudent será chamada recursivamente para processar o próximo estudante (i + 1).

Se canContinue for false, significa que o buffer interno do writeStream está cheio, então a aplicação pausará a escrita e aguardará o evento drain, que será emitido quando o buffer for esvaziado (ou seja, quando há espaço para novos dados).

Quando o evento drain for emitido, a função writeStudent será chamada novamente para continuar o processo, recebendo o contador atual +1, no caso i+1.

Se executarmos nosso script agora e verificarmos o consumo de memória no gerenciador do sistema operacional, percebemos que o processo vai ter um uso de memória constante, sem variações para um pico elevado de consumo de memória:

Isso acontece porque agora estamos controlando nossa escrita para ela ser feita somente quando o writeStream estiver pronto para receber mais dados.

E teríamos outra forma de fazer isso sem a recursão e sem ter que lidar com o controle manual do backpressure?

É claro! Vamos a mais uma alternativa de implementação!

Resolvendo backpressure com funções geradoras e pipelines

Primeiro vamos adicionar mais dois imports no começo do arquivo:

Em seguida vamos novamente substituir apenas a função generateStudentsWithStreams:

Agora vamos analisar o código, começando pela nossa generator function presente em generateStudentsWithStreams:

Com o uso do operador * podemos criar uma função geradora, que permite a geração de dados sob demanda, retornando os dados também sob demanda através do operador yield.

É possível dizer que o yield é uma espécie de retorno incremental, que pode ser chamado diversas vezes até que não tenhamos mais dados para retornar.

Então utilizamos o Readable.from, que cria uma stream de leitura a partir de um iterável (no caso, um gerador que é o nosso generateStudents).

É aqui que está o segredo, pois o Readable.from vai cuidar automaticamente do backpressure, pausando a geração de dados quando o consumidor writeStream não estiver pronto.

Em seguida criamos nossa stream de escrita, passando o caminho/nome do arquivo que desejamos escrever como parâmetro:

Por fim, utilizamos o pipeline para poder conectar a stream de leitura com a stream de escrita.

Agora podemos executar o script novamente e acompanhar nosso consumo de memória no gerenciador de tarefas. Ele deve permanecer baixo e com um valor constante.

Streams e readline

Ainda seguindo o nosso exemplo do relatório de alunos, poderíamos então ler o relatório, aplicar uma regra de negócio a cada linha e criar um novo relatório a partir disso? A resposta é sim!

Agora que aprendemos a lidar com nossos buffers implícitos, podemos utilizar o módulo readline para criar uma interface de leitura mais simples, que vai ler linha por linha do relatório e passar para escrita apenas uma linha por vez.

Isso faz com que o nosso buffer atual tenha apenas o tamanho em bytes necessário para a linha processada a cada vez.

Para esse exemplo, eu vou apenas utilizar aqueles 3 primeiros alunos usados anteriormente em vez do nosso relatório gigantesco. Você pode escolher usar outros registros para teste, se quiser.

E vamos mais uma vez criar um novo arquivo para executar o seguinte script:

Começamos criando uma stream de leitura e em seguida uma const chamada rl, que ao utilizar do módulo readline, irá criar uma interface para nossa stream de leitura ser lida linha por linha.

Em seguida, vamos criar nossa stream de escrita e um contador de bytes apenas para fins didáticos.

Nesse caso, vamos comparar se mesmo utilizando o readline, a quantidade de bytes do nosso buffer vai ser igual ao nosso primeiro exemplo, que foi de 535.

Dentro do for await vamos medir quantos bytes tem o buffer atual, ou seja, a linha que está sendo percorrida nesse momento. Depois printamos esse valor e somamos ao totalizador, para no final termos a somatória de todas as linhas.

Como a aplicação lê uma linha por vez e definimos que cada linha deve ser convertida de buffer bruto para utf-8, só precisamos converter a linha atual em um objeto JavaScript com JSON.parse. Com isso podemos manipular os dados como quisermos!

Então criamos uma condicional para informar que apenas estudantes com média final maior ou igual a 6 vão ser incluídos no novo relatório.

Definimos que stream de leitura deve escrever apenas aquela linha, que será novamente transformada em string com uma quebra de linha para manter o formato *.ndjson de nosso relatório.

Dessa forma, a stream de escrita recebe um buffer apenas do tamanho da linha atual, e não o relatório todo, já que estamos fazendo isso incrementalmente pelo nosso for await.

Ao executar o script teremos a seguinte saída:

Isso mostra o tamanho do buffer correspondente a cada linha que estamos tentando ler. Temos dois bytes a mais pois o readline remove a quebra de linha que temos no final. Se contarmos as quebras de linha da linha 1 e linha 2, teríamos os mesmos 535 bytes.

Caso deseje, você pode executar o mesmo script passando o relatório com um milhão (1_000_000) de alunos, e acompanhar o gerenciador de tarefas novamente.

Repare que o consumo de memória vai se manter baixo, com uma pequena variação dependendo do tamanho da linha sendo processada, mas nada que extrapole o uso de memória como no primeiro caso, em que não tínhamos o tratamento de backpressure.

Conclusão

O uso de buffers permite a criação de um espaço na memória de rápido acesso e torna nossas operações muito mais rápidas, em comparação com strings normais.

Buffers são aliados poderosos das streams, usadas para transmitir dados sob demanda sem a necessidade de carregar todos esses dados em memória, o que mantém um fluxo contínuo de escrita e leitura de informações.

Importante: Caso não façamos a definição do buffer explicitamente para a stream, ela irá lidar com isso de maneira implícita, o que pode gerar problemas de backpressure e um alto consumo de memória durante a escrita dos dados.

Por fim, vimos algumas maneiras de lidar com o backpressure:

• Lidando diretamente com o intervalo de limpeza do buffer interno do Node.js;
• Delimitando a quantidade de informações sendo transmitidas e escritas, para que o buffer interno tenha apenas o tamanho do dado a ser transmitido. Dessa forma, um fluxo contínuo de entrega e um baixo consumo de memória são permitidos.