El Modelo EventEmitter de Node.js

EventEmitter es el patrón que Node utiliza para permitir que una parte de un programa anuncie que algo ha sucedido, sin necesidad de saber quién, si es que alguien, está escuchando. Es una de las APIs más antiguas en el módulo node:events de Node, y una de las más fundamentales: streams, servidores HTTP, sockets y procesos hijos son todos, debajo de sus APIs específicas, EventEmitters.

Conceptos básicos de EventEmitter cubre la API práctica on/once/emit, y Fugas de memoria de los listeners, EventEmitter tipado y Eventos de dominio vs EventEmitter profundizan en una preocupación específica. Esta página es el modelo mental subyacente a todos ellos: qué hace realmente la emisión de un evento, cómo difiere de una cola o un bus de mensajes, y dónde su diseño síncrono y en proceso comienza a importar.

Resumen

• EventEmitter es un mecanismo de publicación/suscripción síncrono y en proceso: un objeto mantiene una lista de eventos con nombre, y cualquier número de funciones listener puede suscribirse a cada nombre.
• Por qué es importante: Desacopla el código que detecta que algo sucede del código que reacciona a ello, sin necesidad de que ninguna de las partes se conozca directamente.
• Conceptos clave: emisor, listener, nombre del evento, emit, despacho síncrono, desacoplamiento.
• Cuándo usarlo: Modelar notificaciones en proceso (un trabajo terminado, una conexión cerrada, un valor cambiado), construir un sistema de plugins/hooks, o trabajar con cualquier API central de Node que ya exponga eventos (streams, servidores, sockets).
• Limitaciones / Compromisos: EventEmitter es completamente en memoria y síncrono por llamada de listener; no tiene persistencia, ni entrega entre procesos, y un listener lento o que lanza un error afecta directamente al llamador del emisor.
• Temas relacionados: API de streams de Node, el bucle de eventos y la pila de llamadas, colas de mensajes, el patrón de diseño observador.

Fundamentos

La idea central detrás de EventEmitter es el patrón observador: un objeto (el emisor) expone eventos con nombre, otro código registra funciones listener contra esos nombres, y llamar a emit(nombre, ...) ejecuta cada listener actualmente registrado para ese nombre. Ninguna de las partes necesita una referencia a la otra más allá de la propia instancia compartida del emisor; el emisor no sabe ni le importa quién está escuchando, y un listener no necesita saber qué lo activó más allá del nombre y la carga útil del evento.

Una analogía útil: piensa en un emisor como el sistema de alarma contra incendios de un edificio en lugar de una llamada telefónica. Al tirar de la alarma (emit) no se marca a una persona específica, sino que suena cada campana de alarma registrada (listener) en el edificio a la vez, y la persona que tira de la palanca no necesita saber cuántas personas hay dentro o quiénes son.

import { EventEmitter } from 'node:events';
 
const uploads = new EventEmitter();
 
uploads.on('completed', (fileId: string) => {
  console.log(`upload finished: ${fileId}`);
});
 
uploads.emit('completed', 'file-123'); // ejecuta cada listener de 'completed', en orden

Node adoptó este patrón temprano porque gran parte de lo que hace un servidor tiene inherentemente forma de evento: un socket recibe datos, una solicitud se completa, un proceso hijo termina. En lugar de inventar una convención de callback a medida para cada uno de ellos, Node estandarizó un mecanismo compartido y luego construyó muchas de sus propias clases centrales directamente sobre él.

Mecánica e Interacciones

El hecho mecánico más importante sobre EventEmitter es que es síncrono: llamar a emitter.emit(nombre, ...) invoca a cada listener registrado para ese nombre, uno tras otro, en la pila de llamadas actual, y emit() solo regresa después de que todos ellos hayan regresado. Esto es fundamentalmente diferente de una cola de mensajes o un broker de pub/sub; no hay almacenamiento en búfer, no hay garantía de entrega y ningún listener registrado después de una llamada a emit() recibe esa emisión en particular.

emitter.on('tick', () => console.log('A'));
emitter.on('tick', () => console.log('B'));
emitter.emit('tick');
console.log('C');
// Salida: A, B, C - ambos listeners se ejecutan hasta su finalización,
// sincrónicamente, antes de que emit() regrese y se registre 'C'.

Esa sincronicidad tiene una consecuencia directa para el manejo de errores: si un listener lanza un error, la excepción se propaga desde emit() mismo, al igual que cualquier otro lanzamiento síncrono; no es capturada ni tragada por el emisor, y detiene la ejecución de cualquier listener posterior para esa misma emisión. Para el evento especial 'error' específicamente, Node añade una regla más: si un emisor emite 'error' sin ningún listener registrado para él, Node lo trata como una excepción no capturada y bloquea el proceso, precisamente porque un error ignorado silenciosamente es peor que uno ruidoso.

El otro detalle mecánico que vale la pena internalizar es por qué tantas APIs centrales de Node extienden EventEmitter en lugar de exponer una forma de callback diferente: le da a cada stream, servidor y socket una forma uniforme de exponer múltiples señales, a las que se puede suscribir de forma independiente ('data', 'error', 'close', 'end', y más) desde un solo objeto, en lugar de necesitar un argumento de constructor o método separado para cada una. Una vez que entiendes el EventEmitter simple, ya entiendes la forma de stream.Readable, net.Server y child_process.ChildProcess: superponen nombres de eventos específicos del dominio sobre el mecanismo exacto descrito anteriormente.

Consideraciones y Aplicaciones Avanzadas

La mayor limitación estructural de EventEmitter es también su compromiso definitorio: es completamente en proceso y en memoria. No hay persistencia (un listener registrado después de que se dispara un evento nunca lo ve), no hay garantía de entrega y no hay durabilidad entre procesos o reinicios; un emisor y sus listeners deben vivir en el mismo proceso en ejecución, compartiendo el mismo espacio de memoria.

Eso lo convierte en una herramienta fundamentalmente diferente de una cola de mensajes o un bus de eventos, aunque ambos a veces se denominan vagamente "eventos". Eventos de dominio vs EventEmitter cubre exactamente dónde se encuentra esa línea: EventEmitter se adapta a notificaciones rápidas, en proceso y de mejor esfuerzo (actualizaciones de UI, hooks internos, señalización de streams), mientras que las colas (Kafka, SQS, RabbitMQ o un patrón de bandeja de salida) se adaptan a cualquier cosa que necesite sobrevivir a un reinicio, cruzar un límite de proceso o garantizar una entrega al menos una vez.

Vale la pena mencionar dos modos de fallo operativos porque aparecen repetidamente en los servicios de Node en producción. Primero, la acumulación de listeners: una llamada a on() sin una off()/removeListener() correspondiente mantiene ese listener (y todo lo que cierra) vivo durante toda la vida útil del emisor, lo que es una fuente rutinaria de crecimiento de memoria en procesos de larga duración. La advertencia predeterminada maxListeners de Node (10 por nombre de evento) existe específicamente como un detector de humo temprano para esto, no como un límite estricto. Fugas de memoria de los listeners cubre la limpieza basada en AbortSignal y cuándo aumentar ese límite es legítimo versus una señal de una fuga real.

Segundo, la seguridad de tipos a escala: las firmas emit/on de un EventEmitter simple aceptan cualquier cadena como nombre de evento y cualquier argumento como carga útil, lo que significa que un nombre de evento mal escrito o una forma de carga útil no coincidente es invisible para el compilador de TypeScript por defecto. EventEmitter tipado cubre la restricción de ambos extremos (nombres y formas de carga útil) para que esos errores salgan a la luz en tiempo de compilación en lugar de no hacer nada silenciosamente en tiempo de ejecución.

Conceptos erróneos comunes

• "emit() es asíncrono, como la mayoría de las otras E/S de Node." Es completamente síncrono: cada listener se ejecuta, en orden de registro, en la pila de llamadas actual, antes de que emit() regrese; nada sobre EventEmitter en sí mismo pospone la ejecución a un tick posterior.
• "EventEmitter es básicamente una cola de mensajes ligera." Una cola almacena en búfer y persiste mensajes para una entrega posterior o repetida; EventEmitter no tiene ningún búfer en absoluto: si nada está escuchando cuando se ejecuta emit(), esa emisión simplemente desaparece.
• "Un error lanzado dentro de un listener es capturado por el emisor." Se propaga exactamente como cualquier lanzamiento síncrono, interrumpiendo potencialmente a los listeners posteriores para esa misma emisión y apareciendo en el sitio de la llamada a emit(): el emisor no proporciona un try/catch implícito.
• "maxListeners es un límite estricto que comenzará a eliminar listeners." Solo activa una advertencia (MaxListenersExceededWarning) una vez superado; es una heurística de detección de fugas, no un límite impuesto, y aumentarlo es a veces la solución correcta en lugar de ser siempre una señal de alerta.
• "Solo el código de aplicación personalizado usa EventEmitter; las APIs centrales de Node tienen lo suyo." Lo contrario es cierto: streams, servidores HTTP, sockets y procesos hijos son todos EventEmitters debajo de sus nombres de método específicos, utilizando este mismo mecanismo.

Preguntas frecuentes

Relacionado

• Conceptos básicos de EventEmitter - ejemplos prácticos de on/once/emit
• Fugas de memoria de los listeners - acumulación de listeners y limpieza con AbortSignal
• EventEmitter tipado - restringiendo nombres de eventos y cargas útiles en tiempo de compilación
• Eventos de dominio vs EventEmitter - cuándo una cola es la herramienta adecuada en su lugar
• Cómo funcionan los Streams de Node.js - el consumidor incorporado más común de este patrón

Versiones de la pila: Esta página fue escrita para Node.js 24 LTS y TypeScript 5.6+.