RobCo vira unicórnio: onde o Bun entra na robótica

A RobCo, startup alemã de Munique, acaba de virar unicórnio: segundo o Tech Funding News, a empresa agora vale US$ 1 bilhão. Ela vende robôs industriais modulares para fábricas pequenas e médias, o tipo de cliente que nunca teve dinheiro nem equipe para um projeto de automação tradicional. Você deve estar se perguntando o que isso tem a ver com Bun. Mais do que parece. O braço robótico é a parte que aparece na foto, mas quem paga a conta é o software em volta dele. E boa parte desse software é exatamente o tipo de coisa que eu escreveria em TypeScript amanhã de manhã.

O que a RobCo faz, sem o hype

A ideia é simples de explicar. Em vez de um robô fechado, caro e montado sob medida por um integrador, a RobCo entrega módulos: juntas, elos, garras. Você monta a configuração que a sua linha precisa. A programação é feita por uma interface visual, sem exigir um engenheiro de robótica na folha de pagamento.

O modelo de negócio também ajuda. A empresa aposta em robô como serviço, com pagamento recorrente em vez de um investimento gigante de uma vez. Para uma fábrica de 40 funcionários, isso muda tudo. Ela deixa de comprar uma máquina e passa a assinar uma capacidade.

E aqui está o detalhe que interessa a quem programa. Assinatura exige telemetria. Se você cobra por mês, precisa saber se o robô está ligado, quantos ciclos fez, quando vai falhar. Isso não roda no braço. Roda num backend.

Por que um unicórnio de robótica importa para dev web

Dinheiro de investidor em hardware costuma virar contratação de software. Toda empresa de robô modular vira, com o tempo, uma empresa de plataforma. Ela precisa de:

• painel web para o cliente acompanhar a frota;
• API para integrar com ERP e sistema de produção;
• ingestão de dados de sensores em tempo real;
• atualização remota de configuração e firmware.

Nenhum desses itens é controle de motor. São problemas que você já resolveu em SaaS comum, só que com um cliente que fica numa fábrica com Wi-Fi ruim e poeira no roteador.

O robô se mexe em C++. O negócio se mexe em JSON.

Essa é a minha opinião forte do dia: a camada de controle em tempo real continua sendo território de C++, Rust e ROS, e deve continuar assim. Ninguém sério vai fechar malha de controle de servo motor com garbage collector. Mas a camada de cima, a que conversa com gente e com outros sistemas, está totalmente aberta para runtimes de JavaScript. E é ali que o Bun fica interessante.

Onde o Bun cabe na robótica de verdade

O ponto de encontro entre fábrica e nuvem costuma ser um gateway: um computador pequeno, muitas vezes ARM, perto das máquinas. Ele coleta dados, guarda quando a internet cai e envia quando volta. É um trabalho chato e importante.

O Bun resolve três dores desse cenário de uma vez.

Um binário só. Instalar Node, npm e node_modules num gateway industrial é pedir para dar errado. Com o Bun você compila tudo num executável:

bun build ./gateway.ts --compile --target=bun-linux-arm64 --outfile gateway

Você copia um arquivo para a máquina e roda. Sem gerenciador de pacotes na fábrica, sem "na minha máquina funciona".

SQLite embutido. O bun:sqlite já vem no runtime. Para um buffer local de leituras, é exatamente o que você precisa, sem dependência nativa para compilar no ARM.

WebSocket nativo. O Bun.serve aceita WebSocket direto, sem biblioteca extra. Para receber dados de várias células de produção ao mesmo tempo, isso basta.

Um gateway de telemetria em poucas linhas

Veja um exemplo mínimo. As células mandam leituras por WebSocket, o gateway grava tudo no SQLite local e um laço separado envia para a nuvem.

import { Database } from "bun:sqlite";

const db = new Database("buffer.db");
db.run("PRAGMA journal_mode = WAL;");
db.run(`CREATE TABLE IF NOT EXISTS leituras (
  id INTEGER PRIMARY KEY,
  robo TEXT NOT NULL,
  payload TEXT NOT NULL,
  ts INTEGER NOT NULL
)`);

const inserir = db.prepare(
  "INSERT INTO leituras (robo, payload, ts) VALUES (?, ?, ?)"
);

Bun.serve({
  port: 8080,
  fetch(req, server) {
    if (server.upgrade(req)) return;
    return new Response("gateway ok");
  },
  websocket: {
    message(ws, msg) {
      const { robo, dados } = JSON.parse(String(msg));
      inserir.run(robo, JSON.stringify(dados), Date.now());
    },
  },
});

E o envio, que só apaga o que a nuvem confirmou:

const pendentes = db.prepare(
  "SELECT id, robo, payload, ts FROM leituras ORDER BY id LIMIT 500"
);
const apagarAte = db.prepare("DELETE FROM leituras WHERE id <= ?");

setInterval(async () => {
  const lote = pendentes.all() as { id: number }[];
  if (lote.length === 0) return;

  const res = await fetch("https://api.exemplo.com/telemetria", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(lote),
  }).catch(() => null);

  if (res?.ok) apagarAte.run(lote.at(-1)!.id);
}, 5_000);

Repare na regra de ouro: o dado só sai do disco depois do 200. Se a internet da fábrica cair por três horas, as leituras ficam no SQLite esperando. Quando a conexão volta, o laço drena a fila em lotes de 500. Nada de Kafka, nada de broker, nada de cluster. Para um gateway com uma dúzia de robôs, isso aguenta tranquilo.

Claro que não é código de produção pronto. Falta autenticação no WebSocket, validação do payload e um limite de tamanho para o banco não encher o cartão SD. Mas a estrutura é essa, e cabe numa tela.

Os limites que você precisa respeitar

Seria desonesto vender o Bun como resposta para tudo em robótica. Não é.

Primeiro, tempo real. Um runtime com GC pode pausar alguns milissegundos em momento inconveniente. Para telemetria, isso não importa. Para parar um braço antes que ele acerte uma pessoa, importa muito. Segurança funcional fica no controlador, com hardware certificado. Seu TypeScript nunca deve estar nesse caminho.

Segundo, protocolos industriais. O chão de fábrica fala OPC UA, Modbus, às vezes coisas proprietárias dos anos 90. O ecossistema JavaScript tem bibliotecas para isso, mas a maturidade varia. Antes de escolher o runtime, confira se o protocolo do seu cliente tem um cliente decente. Às vezes a resposta certa é um processo pequeno em outra linguagem fazendo a ponte, e o Bun cuidando do resto.

Terceiro, compatibilidade com Node. Melhorou muito, mas pacote que depende de addon nativo antigo ainda pode dar dor de cabeça no ARM. Teste no hardware real, não só no seu notebook. O gateway da fábrica não tem o mesmo humor que o seu MacBook.

O que muda no seu dia a dia

Se você trabalha com backend TypeScript, a notícia da RobCo é um lembrete de mercado. Robótica deixou de ser nicho de engenheiro mecatrônico. Empresas como essa precisam de gente que saiba fazer API, fila, painel, autenticação e deploy confiável. É o seu trabalho de sempre, só que com um cliente que mede sucesso em peças por hora.

Na prática, três coisas valem o seu tempo:

1. Aprender a pensar offline primeiro. Fábrica cai da internet o tempo todo, e o seu código precisa tratar isso como caso normal, não como exceção.
2. Dominar bun build --compile e cross-compilation. Entregar um binário único é um superpoder em ambiente que você não controla.
3. Entender o mínimo de OPC UA ou MQTT. Você não precisa virar especialista, mas precisa saber ler a documentação do equipamento.

Minha opinião final: o valor de US$ 1 bilhão não está no alumínio do braço. Está na promessa de que uma fábrica pequena consegue automatizar sem contratar um integrador caro. Essa promessa só se cumpre com software simples, robusto e fácil de instalar. O Bun não faz robô andar, mas faz o resto chegar na fábrica com menos atrito. Se quiser ver como eu aplico essa mesma lógica de binário único e backend enxuto em projetos reais, dá uma olhada nos meus projetos.

A RobCo acaba de virar unicórnio. E o que me chamou atenção nem foi o braço robótico.

Quem paga a conta é o software em volta dele: telemetria, painel, API, atualização remota.

O robô se mexe em C++. O negócio se mexe em JSON.

O controle em tempo real continua com C++ e Rust, e é bom que continue assim. Mas o gateway que fica na fábrica cabe num binário Bun, com SQLite embutido e WebSocket nativo.

A regra é simples: o dado só sai do disco depois que a nuvem confirma. A internet da fábrica pode cair por três horas e nenhuma leitura se perde.

Robótica deixou de ser nicho de mecatrônica. Ela precisa de quem sabe fazer API, fila e deploy confiável.

Escrevi o passo a passo com código no blog. Se você trabalha com backend TypeScript, vale a leitura.

#Bun #TypeScript #Robotica #IoT #Backend