Actores en el navegador y más allá: XState, workers y actores duraderos

Hay una ironía histórica en que la comunidad de JavaScript haya descubierto el modelo de actores como una novedad importada, porque el entorno en el que trabaja es, desde su primer día, un runtime de actores encubierto. Un hilo único, una cola de tareas que se atiende de una en una y una regla de ejecución hasta el final que impide que dos manejadores se solapen: eso es un buzón y eso es un turno, aunque la especificación no use esas palabras. Reconocer la equivalencia cambia la lectura de todo lo demás. XState v5 deja de parecer una librería con vocabulario exótico y se convierte en la formalización de algo que ya estaba ahí, y los workers, los Durable Objects y los granos de Orleans dejan de ser tecnologías inconexas para revelarse como el mismo modelo estirado sobre fronteras cada vez más caras de cruzar.

El bucle de eventos ya era un runtime de actores

La correspondencia es literal, no metafórica. La cola de tareas es el buzón. Encolar una tarea es enviar un mensaje. La regla de ejecución hasta el final —una tarea no se interrumpe a la mitad— es la atomicidad del turno, y es exactamente lo que garantiza que ningún otro manejador observe un estado intermedio. Lo que el entorno no trae es la otra mitad del modelo: no hay direcciones, no hay una frontera que impida que dos manejadores toquen el mismo objeto, y por tanto el aislamiento hay que imponerlo por disciplina. Un runtime de actores en el navegador no añade concurrencia, añade fronteras a una concurrencia que ya existía.

La fila del aislamiento es la que justifica que exista una librería. Sin frontera, dos manejadores pueden mutar el mismo objeto en turnos distintos y producir estados que nadie diseñó, que es la versión suave y muy común de la carrera clásica: no hay corrupción de memoria, pero sí una secuencia de escrituras que ninguna especificación contemplaba. La máquina restituye la frontera declarando qué eventos acepta cada estado y prohibiendo estructuralmente que el estado se toque fuera de una transición.

XState v5: dirección, sistema y lógicas de actor

En la versión cinco la unidad central dejó de ser la máquina y pasó a ser el actor, y esa reorganización tiene consecuencias visibles en cada API. Una referencia de actor es la dirección de Hewitt: opaca, sin acceso al estado interno, solo apta para enviar. Crear un hijo es el segundo verbo. Y el reparto de lógicas —promesa, retrollamada, observable, transición, máquina— dice algo importante: no todo actor tiene que ser una máquina de estados, porque el modelo nunca lo exigió. Una promesa envuelta es un actor de un solo mensaje de salida y ciclo de vida corto, y eso basta para que participe del sistema con las mismas reglas que los demás.

import { setup, assign, sendTo, fromCallback } from 'xstate'

const puente = fromCallback<{ type: string }>(({ sendBack, receive }) => {
  const worker = new Worker(new URL('./calculo.ts', import.meta.url), { type: 'module' })
  worker.onmessage = (ev) => sendBack(ev.data)   // el buzon del padre
  receive((evento) => worker.postMessage(evento)) // el buzon del worker
  return () => worker.terminate()                 // fin de vida del actor
})

export const panel = setup({
  types: {
    context: {} as { resultado: number | null },
    events: {} as { type: 'CALCULAR' } | { type: 'RESULTADO'; valor: number },
  },
  actors: { puente },
}).createMachine({
  initial: 'listo',
  context: { resultado: null },
  invoke: { id: 'motor', src: 'puente', systemId: 'motor' },
  states: {
    listo: {
      on: {
        CALCULAR: { actions: sendTo('motor', { type: 'CALCULAR' }) },
        RESULTADO: { actions: assign({ resultado: ({ event }) => event.valor }) },
      },
    },
  },
})

La fricción real llega cuando se intenta cobrar la transparencia de ubicación que el modelo promete. Una referencia de actor en XState es un objeto de JavaScript vivo en la memoria del hilo: no se serializa, no viaja y no significa nada al otro lado de una frontera. Para que un actor pueda mudarse hacen falta tres cosas que el runtime no da hechas: direcciones que sean datos y no punteros, un transporte que las resuelva, y eventos que sean serializables de principio a fin. La tercera es la que más disciplina exige y la que más se agradece después, porque obliga a que los eventos sean datos planos en lugar de objetos con métodos o cierres, y esa restricción es justo lo que permite registrarlos, reproducirlos y auditarlos.

Cruzar el hilo: workers, clonado y la puerta abierta

Un worker es el actor mejor implementado que ofrece la plataforma: aislamiento total de memoria, una cola de mensajes propia, y un envío que copia el contenido en lugar de compartirlo. El clonado estructurado no es un detalle de rendimiento sino el mecanismo que hace cierto el aislamiento: al copiar, garantiza que emisor y receptor no puedan observar la misma celda de memoria jamás. Los objetos transferibles añaden un matiz elegante: en vez de copiar, mueven la propiedad y dejan inutilizable el original en el emisor, que es una transferencia lineal de propiedad con el mismo espíritu que el sistema de tipos de Rust y con el mismo efecto de no dejar dos dueños vivos.

flowchart LR
UI[hilo principal como actor] -- postMessage con copia --> W1[worker de calculo]
W1 -- resultado --> UI
UI -- postMessage --> W2[worker de sincronizacion]
W2 -- eventos --> UI
SAB[memoria compartida] -. reabre carreras reales .-> W1
SAB -. reabre carreras reales .-> UI
style UI fill:#89b4fa,color:#11111b
style SAB fill:#f38ba8,color:#11111b

La única puerta que reabre las carreras verdaderas es la memoria compartida entre hilos, y conviene entender que no es una versión suave del problema: dos hilos escribiendo el mismo búfer sin sincronizar producen carreras de datos con toda su fenomenología clásica, incluidas las reordenaciones del compilador y del procesador que las operaciones atómicas existen para domar. La regla de diseño es simple de enunciar y difícil de sostener bajo presión de rendimiento: usa memoria compartida solo dentro de una frontera bien delimitada, con operaciones atómicas explícitas, y nunca la expongas como si fuera parte del protocolo de mensajes.

Actores duraderos: la nube redescubre el buzón

Cuando el actor tiene que sobrevivir al proceso, aparecen dos familias con filosofías opuestas y vale la pena verlas juntas.

Los objetos duraderos aportan una idea que cierra el círculo con la lección del buzón. Su puerta de entrada encola los mensajes que llegan mientras una operación de almacenamiento está en vuelo, de modo que el turno vuelve a ser atómico incluso atravesando una espera: la plataforma resuelve por ti el problema del turno partido en vez de pedirte disciplina. A cambio, cada objeto es una instancia única en todo el mundo para su identificador, lo que lo convierte a la vez en una frontera de consistencia perfecta y en un punto de serialización cuyo rendimiento máximo es el de un solo turno detrás de otro.

// Un actor duradero: identidad derivable, estado colocado, turno protegido.
export class Sala {
  private estado: DurableObjectState
  constructor(estado: DurableObjectState) {
    this.estado = estado
  }

  async fetch(peticion: Request): Promise<Response> {
    const evento = await peticion.json()
    // La lectura y la escritura ocurren dentro del mismo turno logico:
    // los mensajes que lleguen mientras tanto quedan encolados por la plataforma.
    const votos = (await this.estado.storage.get<number>('votos')) ?? 0
    await this.estado.storage.put('votos', votos + 1)
    return Response.json({ votos: votos + 1, evento })
  }
}

// La direccion se calcula, no se consulta a ningun directorio.
const referencia = (env: Env, nombre: string) =>
  env.SALAS.get(env.SALAS.idFromName(nombre))

Compara ese fragmento con el manejador partido de la lección anterior y verás la diferencia de fondo: aquí también hay una espera en medio del turno, pero la plataforma retiene los mensajes entrantes mientras dura, de modo que la atomicidad que en el navegador tenías que defender con disciplina la sostiene el runtime. Es la misma garantía del modelo, comprada con infraestructura en lugar de con convenciones, y por eso un objeto duradero admite código secuencial ingenuo sin volverse incorrecto.

El actor virtual elige el camino contrario. En ese modelo un grano no se crea ni se destruye: existe siempre por definición, y el runtime lo activa cuando llega un mensaje y lo desactiva cuando lleva tiempo ocioso. Desaparecen el ciclo de vida, el registro de direcciones y la pregunta de si el destinatario está vivo, y el programador escribe como si todas las entidades del dominio estuvieran instanciadas a la vez. El precio es coherente con la ganancia: si nadie crea ni supervisa, tampoco hay un padre con contexto para decidir la reparación, y la recuperación se reduce a reactivar en otro nodo. Se gana simplicidad de programación y se pierde la topología de confianza que hacía tan expresivo el árbol de supervisión.