RobCo se convierte en unicornio: dónde entra Bun en la robótica

RobCo, una startup alemana de Múnich, acaba de convertirse en unicornio: según Tech Funding News, la empresa ahora vale US$ 1.000 millones. Vende robots industriales modulares a fábricas pequeñas y medianas, el tipo de cliente que nunca tuvo dinero ni equipo para un proyecto de automatización tradicional. Seguro te estás preguntando qué tiene que ver esto con Bun. Más de lo que parece. El brazo robótico es lo que sale en la foto, pero lo que paga las cuentas es el software que lo rodea. Y buena parte de ese software es justo el tipo de cosa que yo escribiría en TypeScript mañana por la mañana.

Qué hace RobCo, sin el hype

La idea es fácil de explicar. En lugar de un robot cerrado, caro y armado a medida por un integrador, RobCo entrega módulos: articulaciones, eslabones, pinzas. Tú montas la configuración que tu línea necesita. La programación se hace con una interfaz visual, sin exigir un ingeniero en robótica en la nómina.

El modelo de negocio también ayuda. La empresa apuesta por el robot como servicio, con pago recurrente en lugar de una inversión enorme de una sola vez. Para una fábrica de 40 empleados, eso lo cambia todo. Deja de comprar una máquina y pasa a suscribirse a una capacidad.

Y aquí está el detalle que le interesa a quien programa. Una suscripción exige telemetría. Si cobras por mes, necesitas saber si el robot está encendido, cuántos ciclos hizo, cuándo va a fallar. Eso no corre en el brazo. Corre en un backend.

Por qué un unicornio de robótica importa al dev web

El dinero de inversores en hardware suele convertirse en contrataciones de software. Toda empresa de robots modulares termina siendo, con el tiempo, una empresa de plataforma. Necesita:

• un panel web para que el cliente siga su flota;
• una API para integrarse con el ERP y el sistema de producción;
• ingesta de datos de sensores en tiempo real;
• actualización remota de configuración y firmware.

Ninguno de estos puntos es control de motores. Son problemas que ya resolviste en un SaaS común, solo que con un cliente que está en una fábrica con Wi-Fi malo y polvo en el router.

El robot se mueve en C++. El negocio se mueve en JSON.

Esta es mi opinión fuerte del día: la capa de control en tiempo real sigue siendo territorio de C++, Rust y ROS, y debe seguir así. Nadie serio va a cerrar el lazo de control de un servomotor con un garbage collector. Pero la capa de arriba, la que habla con personas y con otros sistemas, está totalmente abierta a los runtimes de JavaScript. Y ahí es donde Bun se pone interesante.

Dónde encaja Bun en la robótica de verdad

El punto de encuentro entre la fábrica y la nube suele ser un gateway: una computadora pequeña, muchas veces ARM, cerca de las máquinas. Recoge datos, los guarda cuando se cae internet y los envía cuando vuelve. Es un trabajo aburrido e importante.

Bun resuelve tres dolores de este escenario de una vez.

Un solo binario. Instalar Node, npm y node_modules en un gateway industrial es buscarse problemas. Con Bun compilas todo en un ejecutable:

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

Copias un archivo a la máquina y lo ejecutas. Sin gestor de paquetes en la fábrica, sin "en mi máquina funciona".

SQLite integrado. bun:sqlite ya viene en el runtime. Para un buffer local de lecturas, es justo lo que necesitas, sin dependencias nativas que compilar en ARM.

WebSocket nativo. Bun.serve acepta WebSocket directamente, sin librerías extra. Para recibir datos de varias celdas de producción al mismo tiempo, alcanza.

Un gateway de telemetría en pocas líneas

Mira un ejemplo mínimo. Las celdas envían lecturas por WebSocket, el gateway guarda todo en el SQLite local y un bucle aparte lo envía a la nube.

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());
    },
  },
});

Y el envío, que solo borra lo que la nube confirmó:

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);

Fíjate en la regla de oro: el dato solo sale del disco después del 200. Si el internet de la fábrica se cae tres horas, las lecturas se quedan en el SQLite esperando. Cuando vuelve la conexión, el bucle vacía la cola en lotes de 500. Nada de Kafka, nada de broker, nada de cluster. Para un gateway con una docena de robots, aguanta sin problema.

Claro que no es código listo para producción. Falta autenticación en el WebSocket, validación del payload y un límite de tamaño para que la base no llene la tarjeta SD. Pero la estructura es esta, y cabe en una pantalla.

Los límites que tienes que respetar

Sería deshonesto vender Bun como la respuesta para todo en robótica. No lo es.

Primero, el tiempo real. Un runtime con GC puede pausar algunos milisegundos en un momento inoportuno. Para telemetría, da igual. Para detener un brazo antes de que golpee a una persona, importa muchísimo. La seguridad funcional se queda en el controlador, con hardware certificado. Tu TypeScript nunca debe estar en ese camino.

Segundo, los protocolos industriales. La planta habla OPC UA, Modbus y a veces cosas propietarias de los años 90. El ecosistema JavaScript tiene librerías para eso, pero la madurez varía. Antes de elegir el runtime, revisa si el protocolo de tu cliente tiene un cliente decente. A veces la respuesta correcta es un proceso pequeño en otro lenguaje haciendo de puente, y Bun encargándose del resto.

Tercero, la compatibilidad con Node. Mejoró mucho, pero un paquete que depende de un addon nativo antiguo todavía puede dar dolores de cabeza en ARM. Prueba en el hardware real, no solo en tu notebook. El gateway de la fábrica no tiene el mismo humor que tu MacBook.

Qué cambia en tu día a día

Si trabajas con backend en TypeScript, la noticia de RobCo es un recordatorio del mercado. La robótica dejó de ser un nicho de ingenieros mecatrónicos. Empresas como esta necesitan gente que sepa hacer API, colas, paneles, autenticación y deploys confiables. Es tu trabajo de siempre, solo que con un cliente que mide el éxito en piezas por hora.

En la práctica, tres cosas valen tu tiempo:

1. Aprender a pensar offline primero. Las fábricas se quedan sin internet todo el tiempo, y tu código tiene que tratarlo como un caso normal, no como una excepción.
2. Dominar bun build --compile y la compilación cruzada. Entregar un solo binario es un superpoder en un entorno que no controlas.
3. Entender lo mínimo de OPC UA o MQTT. No necesitas volverte experto, pero sí saber leer la documentación del equipo.

Mi opinión final: el valor de US$ 1.000 millones no está en el aluminio del brazo. Está en la promesa de que una fábrica pequeña puede automatizar sin contratar a un integrador caro. Esa promesa solo se cumple con software simple, robusto y fácil de instalar. Bun no hace que un robot se mueva, pero hace que el resto llegue a la fábrica con menos fricción. Si quieres ver cómo aplico esta misma lógica de binario único y backend ligero en proyectos reales, échale un vistazo a mis proyectos.

RobCo acaba de convertirse en unicornio. Y lo que me llamó la atención ni siquiera fue el brazo robótico.

Lo que paga las cuentas es el software que lo rodea: telemetría, panel, API, actualización remota.

El robot se mueve en C++. El negocio se mueve en JSON.

El control en tiempo real sigue en manos de C++ y Rust, y está bien que siga así. Pero el gateway que vive en la fábrica cabe en un binario de Bun, con SQLite integrado y WebSocket nativo.

La regla es simple: el dato solo sale del disco cuando la nube lo confirma. El internet de la fábrica puede caerse tres horas y no se pierde ni una lectura.

La robótica dejó de ser un nicho de la mecatrónica. Necesita gente que sepa hacer API, colas y deploys confiables.

Escribí el paso a paso con código en el blog. Si trabajas con backend en TypeScript, vale la pena leerlo.

#Bun #TypeScript #Robótica #IoT #Backend