Aplicaciones Node.js

Node.js, desarrollado y operado junto a tu PHP.

Desarrollamos en Node APIs, sitios renderizados en servidor, servicios en tiempo real y workers, y los ejecutamos en los mismos servidores que tus sitios PHP, detrás de un único Nginx.

Funciona con y creado con
  • Node.js
  • Express
  • npm
  • NGINX
  • MySQL
  • PostgreSQL
  • Redis

Qué desarrollamos en Node

Cinco tipos de trabajo, cada uno aquí porque a Node le sienta bien.

  1. 01

    Express

    APIs y back-ends pequeños y directos: pocas rutas, middleware claro, nada oculto.

    APIs y back-ends
  2. 02

    NestJS

    Servicios más grandes con módulos, inyección de dependencias y contratos tipados en TypeScript, para código que un equipo hará crecer durante años.

    Servicios estructurados
  3. 03

    Next.js · Nuxt

    Renderizado en servidor para React y Vue: las páginas llegan listas para los buscadores y para una primera vista rápida, y luego se comportan como una app.

    Sitios renderizados en servidor
  4. 04

    Socket.IO · WebSockets

    Chat, notificaciones, paneles en vivo y seguimiento que se actualizan en cuanto algo cambia, sobre una sola conexión abierta.

    Tiempo real
  5. 05

    Workers y colas

    Trabajos en segundo plano, tareas programadas y consumidores de colas sobre Redis que mantienen el trabajo lento fuera de la petición.

    Trabajo en segundo plano

Por qué Node sabe esperar

Un proceso de Node ejecuta tu JavaScript en un solo hilo y deja la espera - disco, red, base de datos - al sistema. Así un solo proceso mantiene muchas conexiones abiertas a la vez.

El bucle de eventos de Node.js, simplificado
  1. Tu código se ejecuta en la pila de llamadas, una función cada vez.
  2. El trabajo lento sale del hilo: archivos, DNS y hashing van al pool de libuv, y el sistema operativo vigila los sockets.
  3. Cuando el trabajo termina, su callback espera en la cola de tareas.
  4. Antes de la siguiente tarea se ejecutan todos los callbacks de promesas de la cola de microtareas.
  5. El bucle recorre sus fases y toma la siguiente tarea.

PHP y Node en un solo servidor

Nginx atiende cada petición y envía cada ruta al proceso que le corresponde. Tu sitio PHP y tu servicio Node comparten la máquina, la base de datos y el certificado - no la memoria del otro.

Ejemplo de un servidor que ejecuta ambos

Cuál para cada trabajo

Desarrollamos con los dos, así que la respuesta sale del trabajo, no de una costumbre.

Elige PHP cuando

  • El sitio es sobre todo páginas, formularios y un panel de administración: tiendas, sitios de contenido, sistemas de gestión.
  • Quieres WordPress, WooCommerce o Laravel y todo lo que ya existe para ellos.
  • Cada petición es independiente y termina rápido.
  • Las personas que lo mantendrán ya conocen PHP.

Elige Node cuando

  • Las conexiones se quedan abiertas: chat, paneles en vivo, notificaciones, seguimiento.
  • Las páginas de React o Vue se renderizan en el servidor con Next.js o Nuxt.
  • El servicio pasa la mayor parte del tiempo esperando a otras APIs y dejando pasar flujos de datos.
  • Un solo lenguaje en el navegador y en el servidor ayuda a tu equipo.

A menudo la respuesta es: los dos

PHP se queda con el sitio, la tienda y el panel; un pequeño servicio Node se encarga de la parte en tiempo real a su lado. Los dos leen la misma base de datos y están detrás del mismo Nginx.

Despliegues sin huecos

Una nueva versión arranca junto a la anterior, demuestra que está sana y solo entonces toma el tráfico. Los workers anteriores terminan las peticiones que ya tienen antes de detenerse.

  • Visitantes atendidos
  • Versión actual
  • Nueva versión
  1. 01

    Traer e instalar

    git pull && npm ci

    Las versiones exactas del lockfile, nada más nuevo por sorpresa.

  2. 02

    Compilar

    npm run build

    TypeScript y los recursos se compilan antes de que nada se reinicie.

  3. 03

    Arrancar junto a la anterior

    pm2 reload app

    La nueva versión arranca junto a la que sigue atendiendo.

  4. 04

    Esperar a que esté lista

    wait_ready: true

    Debe responder a su comprobación de salud antes de recibir a un visitante.

  5. 05

    Tomar el tráfico

    cluster → new workers

    Las conexiones nuevas van a la nueva versión.

  6. 06

    Vaciar la anterior

    SIGINT → server.close()

    Los workers anteriores terminan las peticiones que tienen y después se cierran.

Si la nueva versión no supera su comprobación de salud, nunca recibe tráfico: la anterior simplemente sigue atendiendo.

El servidor alrededor del código

Lo que mantiene en pie un servicio Node está escrito en el servidor, en archivos que mantenemos y que tú puedes leer.

  • /etc/nginx/sites-enabled/app.conf

    Proxy inverso

    TLS, compresión, archivos estáticos en caché y actualización a WebSocket, delante de cada proceso.

  • /srv/app/ecosystem.config.js

    Gestor de procesos

    PM2 mantiene vivo el proceso, lo reinicia si se cae y usa cada núcleo en modo clúster. Donde basta un solo proceso, una unidad de systemd hace el mismo trabajo.

  • /srv/app/.env (0600)

    Entorno y secretos

    Las claves y contraseñas viven fuera del código y fuera de git, y solo puede leerlas el usuario propio de la aplicación.

  • /srv/app/package-lock.json

    Auditoría de dependencias

    npm audit en cada versión; las actualizaciones se leen y se prueban antes de llegar a producción.

  • /srv/app/.nvmrc

    Actualizaciones entre versiones LTS de Node

    La aplicación corre sobre una versión de soporte a largo plazo, y la pasamos a la siguiente antes de que la anterior se quede sin soporte.

  • /var/log/app/

    Logs y monitorización

    Logs estructurados y rotados, con una alerta cuando el proceso se reinicia, la memoria sube o aumentan los errores.

Cuatro cifras detrás de cada servicio Node

Cada cifra sale de la documentación de Node.js, libuv o WebSocket y no de mediciones propias, así que puede comprobarla en la fuente.

  • 30meses

    de correcciones para cada versión LTS de Node.js: 12 meses de soporte activo y después 18 de mantenimiento.

    Fuente: Node.js Release Working Group

  • 4hilos

    en el grupo de libuv por defecto, para archivos, DNS y hash. Un ajuste puede subir el grupo hasta 1024.

    Fuente: documentación de libuv

  • 101código de estado

    es cómo un servidor responde a una petición de pasar a WebSocket: Switching Protocols.

    Fuente: RFC 6455

  • 443puerto

    es el puerto al que se conecta por defecto un WebSocket seguro, el mismo que HTTPS, así que la única entrada de Nginx lleva ambos.

    Fuente: RFC 6455

Lo que puede hacer un servicio Node, de un vistazo

Las capacidades en cuatro grupos: qué sirve, qué delega, dónde guarda sus datos y cómo se mantiene en marcha.

Construir y servir

  • API HTTP y REST

    Express solo, o NestJS, que se apoya en Express por defecto y puede usar Fastify en su lugar.

  • TypeScript

    Contratos tipados entre módulos, comprobados al compilar el código, antes de que nada se reinicie.

  • Renderizado en el servidor

    Next.js y Nuxt generan las páginas en el servidor, así que el buscador y quien llega por primera vez reciben HTML terminado.

  • Tiempo real

    Socket.IO empieza con HTTP simple y sube a WebSocket, así que conecta incluso donde un proxy bloquea los WebSockets, y se reconecta solo.

Delegar el trabajo pesado

  • Worker threads

    El JavaScript que exige mucho procesador corre en sus propios hilos y deja libre el bucle de peticiones. Ayudan con el cálculo, no con la espera de E/S.

  • Colas en Redis

    Los trabajos lentos se encolan y terminan en segundo plano, lejos de la petición del visitante.

  • Tareas programadas

    Trabajos que se ejecutan a horas fijas en lugar de esperar a que un visitante los dispare.

  • Modo cluster

    PM2 lanza un worker por núcleo, así que un servicio muy cargado usa toda la máquina y no un solo hilo.

Datos cerca

  • MySQL y PostgreSQL

    El servicio Node y el sitio PHP pueden leer la misma base de datos.

  • Redis

    Sesiones, caché y colas en memoria, compartidas por ambos entornos.

  • Archivos estáticos

    Nginx sirve CSS, imágenes y descargas directamente desde el disco, y Node solo atiende lo que necesita código.

  • Un solo plan de copias

    Un solo plan de copias de seguridad cubre a la vez el sitio PHP y el servicio Node.

Seguir en marcha y al día

  • Reinicio ante fallos

    PM2, o una unidad systemd cuando basta un proceso, recupera un proceso caído.

  • Recarga sin cortes

    Una versión nueva supera su comprobación de salud antes de recibir tráfico.

  • Registros y alertas

    Registros estructurados y rotados, y una alerta cuando el proceso se reinicia, la memoria sube o aumentan los errores.

  • LTS y auditorías

    Una versión de Node con soporte a largo plazo, npm audit en cada versión y secretos guardados fuera del código.

Cuéntanos qué tiene que hacer tu app Node

Un servicio nuevo, un sitio Next.js o una app que ya funciona en algún sitio y necesita un buen hogar. La revisamos y te damos presupuesto tras una conversación breve.

MickeyResponde en segundos