DEV Community: Sam

How I made BeeThreads and what doest it solve

Sam — Fri, 05 Dec 2025 18:35:32 +0000

How I built BeeThreads in 2 days (and now it has 3k+ downloads)

A week ago I was complaining (again) about the same old thing:

“Man, I just want to write normal sync code and in the background with a very simple a manageble DX.”

We’ve all been there. One heavy crypto operation, one giant JSON parse, one dumb recursive Fibonacci… and boom — the event loop is dead. Everyone hates it.

So two days ago I decided to test Claude Opus 4.5 and try to make this real.

I was expecting a half-broken prototype.

Four hours later we had something that actually worked.

And somehow, in less than two days, it’s already at 3k+ downloads.

The dream vs reality

Before (native worker_threads)

// ~50+ lines of pain
const { Worker } = require('worker_threads');
const worker = new Worker('./worker.js');
worker.postMessage(data);
worker.on('message', resolve);
worker.on('error', reject);
worker.on('exit', cleanup);
// plus pooling, timeouts, retries, queue limits… you get it

Would become this:

// bee-threads: 1 line
const result = await bee((x) => x * 2)(21); // 42

But I didn’t want to stop at “it works”. I wanted rock-solid worker management and an absolutely killer developer experience (DX).

Here’s exactly how I made it happen:

I turned the event-driven nature of worker_threads into real Promises on the main thread — so threading feels exactly like writing normal async/await code.

Errors work the same way too: they’re proper Error instances with all custom properties, .cause, stack traces — everything preserved perfectly across thread boundaries.

The biggest challenge (and the magic) is running completely dynamic code inside workers without ever forcing you to create a separate worker file. We do this safely with vm.Script (never eval), and we aggressively cache the compiled functions using an LRU cache.

That means no AST parsing or recompilation on repeated calls — we go from ~0.4 ms (first run) down to ~1–3 µs on cache hits.

There are tons of production-ready features:

Retry with exponential backoff
AbortSignal cancellation
Timeout support
Streaming generators (for await)
Transferable Buffers (coming in next release)

And also ridiculous amount of V8-level optimizations: monomorphic object shapes (no hidden class junk), raw for loops in hot paths, O(1) counters instead of array scans, shared base vm.Context — all the scary stuff… but you never see it. The API stays clean and buttery smooth.

Under the hood, BeeThreads is smart about picking the best worker for each task. It uses function affinity: if a worker has already executed your function, it gets priority. That keeps the code “hot” in V8’s TurboFan JIT, giving you near-native performance after just a few calls.

Here’s some examples:

const { bee } = require('bee-threads');

//Run any function in a separate thread - promise like
const result = await bee((x) => x * 2)(21);  // 42

//Non Blocking I/O in any CPU-Itensive operation.
const hash = await bee((pwd) => 
  require('crypto').pbkdf2Sync(pwd, 'salt', 100000, 64, 'sha512').toString('hex')
)('password123');

//Run with Promise.all
const [a, b, c] = await Promise.all([
  bee((x) => x * 2)(21),
  bee((x) => x + 1)(41),
  bee(() => 'hello')()
]);

You can also write code using method chaining if a very complete API called BeeThreads

const { beeThreads } = require('bee-threads');

await beeThreads
  .run((x) => x * 2)
  .usingParams(21)
  .execute();  // → 42

if you would like to have a try

npm i bee-threads

github: https://github.com/samsantosb/BeeThreads
npm: https://www.npmjs.com/package/bee-threads

Como RUSHAR um serviço assíncrono de envio de dados

Sam — Fri, 02 Feb 2024 01:05:28 +0000

Olá amigos,

Recentemente tive que fazer um projeto para ontem..

Uma dos pontos chave era: Tornar o cadastro de um produto, um cadastro de múltiplos. A feature original se encontrava em um contexto de difícil manutenção (põe diíficil nisso)

O desenvolvimento deveria ser extremamente rápido.

Eis que com um breve refinamento veio a ideia:

Clássica tática de Serverless Async - S3 + SQS + Lambda

Se liga nessa gambi braba...
Ao qual criamos um serviço que faz multi-requests pro nosso endpoint original.

Dessa forma não foi necessário alterar diretamente o domínio da aplicação e criar um novo caso de uso.

A estrutura:

1) Um big array de registros enviado para o endpoint do monolito

2) Monolito salva um JSON no S3, pega o link e envia para um SQS. Ele também envia uma mensagem amigável pro front.

Porque S3 + SQS?

Porque literalmente já vem com a infra pronta, que facilita muito para ganho de tempo.

Mas porque o S3?

O SQS tem um limite no tamanho das mensagens, então uma prática(gambiarra) comum é armazenar dados no S3 e enviar os links de acesso desses dados para a fila.

3) Uma lambda recebe um trigger quando a URL do S3 chega no SQS e consome as mensagens da fila.

Há um pequeno desafio aqui, Lambdas escalam horizontalmente por chamadas... Então..

Como evitar que outra instancia da lambda consuma a mesma mensagem?

Fazer um setup de visibilidade na AWS e apagar/transferir mensagens lidas para outro lugar

4) Lambda faz o download do JSON no S3 e faz multiplas requests pro endpoint de cadastro múltiplo

Há um outro ponto interessante aqui.

Fazer requests uma a uma iria tornar tudo mais trabalhoso e possivelmente daria um timeout na Lambda.

Para resolver esse caso utilizamos o Promise.allSettled() para realizar as requests de maneira paralela e ter um controle melhor das falhas.

As promises com Status Rejected teriam seus dados tratados em outro momento, armazenados em um bucket de logs, ao ponto de permitir enviar por e-mail uma devolutiva para o cliente do porque esses dados não foram cadastrados.

Exemplo do Handler da Lambda:

Exemplo do processamento com Promise.AllSettled:

5) Um último desafio, validar uma AWS Lambda localmente

Hoje com o serverless framework https://www.serverless.com/ é possível reproduzir vários recursos da AWS localmente, mas uma Lambda Trigger com SQS ainda é um desafio CHATISSIMO.

Nesse caso, como Lambdas geralmente são soluções simples e isoladas a opção para validar comportamentos das sub-funções foi Unit Tests.

Não costumo usar unit tests em todos os casos mas visto as limitações de reproduzir alguns padrões da AWS localmente, podem ser uma solução.

Pontos interessantes/Possíveis dúvidas

- Porque não usou generators?
Porque o caso de uso não terá dados tão grandes assim e Lambda tem um tempo limite de execução.

- Porque serverless?
O Endpoint não será utilizado com alta frequência e o tempo de desenvolvimento era restrito.

- S3 com JSONS meu parceiro ????
S3 é o noSQL do povo (em alguns casos)

- Tem DLQ, Retry Bucket pra Logs ??
Tem sim, só não entrei no merito pra tentar ser direto ao caso da solução

- E se a Lambda gargalar ???
Hoje da pra fazer Lambda com GO. Go é bala

Obrigado pela leitura !!

LookUp Table Pattern Javascript

Sam — Thu, 27 Apr 2023 18:24:57 +0000

The LookUp Table Pattern is a design pattern that can be used to map keys to corresponding values. This is particularly useful when we have a large number of keys and want to quickly retrieve the corresponding value.

In the context of JavaScript, a LookUp table can be implemented using an object literal, where the keys represent the keys of the table and the corresponding values represent the values. This way, we can quickly retrieve the corresponding value for a given key.

For example, imagine we have a list of fruits and need to categorize them as sweet or citrus. We can create a LookUp table that maps the fruits to their respective categories. This allows us to quickly categorize a fruit, instead of writing a large number of if/else or switch/case statements.

Moreover, using a LookUp table makes our code more readable and easier to maintain. We can easily add new keys and values to the table without having to modify the function logic.

Javascript Indexing Pattern

Sam — Thu, 27 Apr 2023 18:13:52 +0000

I'm going to start a series of posts about Javascript with some Patterns to share knowledge.

Here's the first Pattern.

The Indexing Pattern is a design pattern that allows easy access to elements in a data collection using a numeric index. In JavaScript, arrays are one of the most common data structures that use the indexing pattern, but we can also use literals, Maps, Sets, Classes with Static Attributes, etc.

It's common that when comparing arrays, we often increase the spatial complexity of the code...

The ideal way to handle this is to use this Pattern. Viable options are Literals, Maps or Classes with Static Attributes.

With this, we can reduce spatial complexity, which can scale exponentially when we chain for loops.