JavaScript en el servidor

Tiene que escribir una API. Recibe una petición HTTP, consulta una base de datos PostgreSQL, llama a dos servicios externos, agrega las respuestas y devuelve JSON. De los 180 milisegundos que dura ese procesamiento, el procesador trabaja quizá 4 milisegundos. Todo lo demás es espera: la red, el disco, la base de datos. Un servidor clásico que asigna un hilo de ejecución por petición mantiene, por tanto, 176 milisegundos de memoria de pila inmovilizada sin hacer nada, multiplicados por el número de peticiones simultáneas. Con mil conexiones activas, esto se convierte en un problema de gigabytes y de cambios de contexto.

Node.js parte de la observación contraria: puesto que el servidor se pasa el tiempo esperando, más vale tener un único hilo de ejecución que procese los eventos a medida que están listos. Una petición que espera a la base de datos no ocupa un hilo, sino una entrada en una tabla de callbacks, es decir, unos pocos cientos de bytes. Es este compromiso, y solo él, el que explica tanto por qué Node soporta muy bien las cargas de tipo entrada/salida como por qué se desploma en cuanto un cálculo algo largo se instala en el hilo único. Comprender este trato antes de escribir la primera línea le ahorrará la mitad de los problemas en producción.