1
capa, sin excepción
Artículo 0 — Del nombre
un middleware, entre tantos. Es El Middleware.
No una capa entre varias posibles: la única capa por la que pasa toda petición antes de convertirse en respuesta. No se elige entre implementaciones — se declara cuál es la que gobierna, y esta lo hace.
Artículo I · De la unicidad
Toda petición que llegue a esta casa —cualquier dominio, cualquier puerta de entrada— pasará por una sola capa. No hay una para cada sitio, ni una para cada equipo. Hay una, y es la que aquí se describe.
Artículo I — Definición
No es una aplicación más. Es lo que decide qué llega a cada una.
Donde otros ven un componente intercambiable, aquí se establece uno solo, con autoridad sobre toda petición: autenticar, medir, limitar, enrutar, cifrar, registrar. Esa lógica no se reparte entre servicios — se concentra, se prueba una vez, y gobierna para todos.
N
aplicaciones que la obedecen
0
rutas que la esquivan
§
una fuente de verdad
Artículo II — Anatomía
Ninguna petición llega directa. Todas cruzan la capa primero.
Cada eslabón decide si deja pasar la petición, la transforma, o corta la cadena y responde él mismo — un 401, un 429, un 503 — sin que la aplicación de destino llegue siquiera a enterarse de que existió.
IN
TLS / borde
Termina el cifrado, identifica el origen real.
01
Enrutamiento
Decide qué aplicación, por dominio, ruta o cabecera.
02
Autenticación
Verifica identidad antes de que el handler la dé por buena.
03
Límite y cuota
Corta lo abusivo antes de que consuma un recurso real.
04
Observabilidad
Registra, mide latencia, sin que la app lo escriba nunca.
OUT
Aplicación
Recibe solo lo que ya pasó cada filtro anterior.
Artículo III — Responsabilidades
Lo que se repetiría en cada servicio, si no hubiera una autoridad única.
I
Enrutamiento
Despacha por dominio, ruta o cabecera. El cliente nunca sabe que hay más de un destino posible.
II
Autenticación
Identidad verificada en un único punto, no reinventada en cada endpoint.
III
Rate limiting
Corta el abuso en la puerta, antes de que consuma cómputo o conexión.
IV
Observabilidad
Un rastro uniforme por petición, sin que cada aplicación implemente su propio logger.
V
Resiliencia
Cuando un destino falla, la capa reintenta, degrada o corta — antes de que el fallo se propague.
Artículo IV — De lo que no basta
Mantener un proceso vivo no es gobernar la entrada.
PM2 resuelve una cosa: reiniciar un proceso Node si cae. No enruta por dominio, no termina TLS, no filtra tráfico. Lo demás se sigue montando aparte — y aparte es exactamente lo que El Middleware no admite.
PM2 + proxy aparte
- Dos procesos independientes: el daemon de PM2 y nginx delante
- TLS y renovación gestionados por separado
- El cluster mode es específico de Node
- El reload de cluster no migra los WebSocket ya abiertos
- El dominio vive en un fichero; el proceso, en otro
El Middleware, capa única
- Un binario: enruta, termina TLS y supervisa el proceso
- Certificados ACME emitidos y renovados por sí mismo
- Agnóstico de runtime — supervisa cualquier comando
- Relevo por fichero puntero: ni un WebSocket se corta
- Dominio y proceso, en el mismo manifiesto
Artículo V — De lo que absorbe
Cada pieza que hoy vive por separado, disuelta en una sola autoridad.
No porque la capa intermedia sea nueva: porque hoy se monta como media docena de herramientas sueltas, cada una con su propia configuración y su propio punto de fallo. El Middleware no coordina esas piezas — las sustituye.
I
nginx / Apache
El proxy inverso y la terminación TLS dejan de vivir en un fichero aparte, con su propia sintaxis y su propio recarga.
II
certbot
Sin cron externo ni hook de post-renovación: la emisión y renovación ACME son parte del mismo proceso.
III
fail2ban / WAF
El filtro por IP, país y agente se evalúa en la misma petición que se enruta, no con retraso.
IV
Auth0 / Access
La puerta de acceso por dominio o ruta se resuelve localmente, sin proveedor externo.
V
supervisor / cron
El ciclo de vida de procesos y las tareas programadas comparten una sola tabla de estado.
Artículo VI — Extensiones
Lo que se enciende cuando hace falta, no lo que viene impuesto.
Ni Cloudflare ni Claude son parte del núcleo: son poderes que se delegan desde el panel, verificados contra el servicio real antes de confiar en ellos, y revocables sin dejar rastro.
Extensión · Cloudflare
Red y certificados, sin salir del panel
Túnel, DNS, reglas de enrutamiento y emisión de certificados gobernados desde un único sitio.
I se declara el dominio
II el panel crea el registro DNS o la regla del túnel
III el certificado se emite y se renueva solo
Extensión · Claude
De un prompt a una app en producción
Levantar una aplicación deja de ser escribir infraestructura a mano: se describe lo que se quiere y el agente ejecuta.
I se aprieta un botón
II se escribe un prompt
III Claude escribe el código y lo despliega
Levantar y crear una app es tan sencillo como apretar un botón,
dar un prompt, y ver cómo Claude hace el trabajo.
Artículo VII — Autocuración
Un sitio caído no espera a que alguien lo note.
La vigilancia de salud no se limita a marcar un punto en rojo en un panel. Cuando un sitio deja de responder y sigue sin hacerlo, El Middleware no se conforma con reiniciarlo a ciegas: llama a Claude, le entrega el manifiesto y el registro, y deja que diagnostique y repare antes de que alguien tenga que abrir un terminal.
I
Vigilancia continua
Cada sitio se sondea a su propio ritmo; una racha de aciertos espacía la siguiente comprobación, un fallo la trae de vuelta al instante.
II
Un umbral, no un reflejo
Tres comprobaciones seguidas en rojo — minuto y medio — antes de actuar. Un despliegue lento no es una caída, y tratarlo como tal enseñaría a ignorar la alarma de verdad.
III
Diagnóstico con Claude
Con el sitio caído, Claude recibe su manifiesto y su registro, entiende qué falla y aplica el arreglo — o dice por qué no puede, en vez de reintentar a ciegas.
IV
Un diario, no un misterio
Cada intervención queda escrita: cuándo empezó, qué se probó, si funcionó. Nadie tiene que reconstruir a las tres de la mañana qué hizo el sistema y por qué.
V
Aviso, no silencio
Quien lleva la casa se entera en el momento, por notificación, de que algo se cayó y de que ya se está reparando — no al abrir el panel por curiosidad.
Si un sitio se cae, Claude lo revisa y
lo repara solo — antes de que nadie tenga que preguntar por qué.
Artículo VIII — Fundamento
La alternativa a una autoridad única es repetir el mismo error N veces.
Sin una capa que gobierne, cada aplicación reimplementa autenticación, límites y registro — con matices distintos, con bugs distintos. Con ella, esa lógica se prueba una vez y se hereda, sin negociación, cada vez que se añade un servicio nuevo.
Sin autoridad única
- Autenticación reimplementada por servicio
- Límites de tasa inconsistentes entre equipos
- Logging con formato distinto por app
- Un cambio de política toca N repositorios
- El fallo de un servicio no se contiene solo
Con El Middleware
- Identidad verificada en un único punto
- Cuota y límites uniformes para toda la casa
- Un formato de traza, una fuente de verdad
- Un cambio de política, un despliegue
- Un fallo se corta en la capa, no se propaga