La semana pasada, un compañero que mantiene una API en Symfony con un panel de administración en Angular me mandó una captura de pantalla: dos archivos abiertos uno junto al otro. A la izquierda, un `UserRegistrationType` con once restricciones; a la derecha, un validador en TypeScript con nueve. Faltaban dos. Nadie sabía qué lado tenía razón, y el ticket del bug llevaba abierto desde marzo. Angular v22 salió en junio de 2026, ahora va por la 22.2.x, y el sello de estable en Signal Forms está a punto de hacer que esa captura sea mucho más habitual en los equipos PHP, salvo que decidamos ya mismo que las reglas son cosa del lado PHP.

Primero, unos datos para que discutamos sobre la misma base. La versión 22 es una release de consolidación. Tres APIs que eran experimentales en la v21 pasan a ser estables: Signal Forms, las señales asíncronas construidas en torno a `resource` para cargar datos del servidor, y Angular Aria, un conjunto de primitivas accesibles sin estilos. El equipo también ha publicado prompts oficiales para LLM, un servidor MCP en el Angular CLI y skills para agentes. Nada de reescrituras ni de modelos mentales nuevos. La actualización se hace con `ng update`, como cada año.

¿Y por qué debería importarle a alguien de Laravel una versión menor de frontend? Porque las APIs estables las adopta la gente que antes estaba esperando, y en los equipos mixtos los que esperaban suelen ser los del backend, a los que les cae un ticket de frontend un jueves por la tarde. Signal Forms te permite expresar la validación como funciones normales de TypeScript. Es una gozada escribirlo. También es el camino más rápido que conozco hacia una segunda copia, que diverge en silencio, de cada regla que ya mantienes en un FormRequest o en una constraint de Symfony, y esa deriva no va a aparecer en los tests porque cada lado se prueba a sí mismo.

Mi postura es esta: el backend PHP es el único sitio donde vive una regla de negocio, y Signal Forms se encarga de mostrar el veredicto. Tu endpoint ya devuelve un 422 con una bolsa de errores estructurada en Laravel, o una lista de violaciones del componente Validator en Symfony. Asigna esos errores a los campos del formulario de forma coherente y en un único sitio del frontend. Las comprobaciones en el cliente se quedan para lo trivial y cosmético: un campo vacío, un email sin @. Todo lo que implique consultar la base de datos, una configuración del tenant o una regla de precios lo decide PHP y lo muestra Angular.

El mejor argumento en mi contra es la latencia y la sensación de fluidez. Esperar una ida y vuelta al servidor para saber que un cupón ha caducado se nota lento comparado con un borde rojo instantáneo, y con una conexión móvil mala, 400 ms por campo convierten un checkout en un suplicio. Es justo. La gente de producto lo va a notar y tendrá razón. Mi respuesta es que un endpoint de validación se puede someter a debounce, y que un mensaje correcto y lento es mejor que uno rápido y erróneo: el rápido y erróneo es el que le dice al cliente que el código es válido, este pulsa pagar y abre un ticket de soporte a las 23:40 cuando el servidor rechaza el pedido igualmente. Prefiero afinar un endpoint que pasarme la vida conciliando dos reglamentos.

La misma lógica se aplica a `resource`. Ahora que cargar datos del servidor mediante señales tiene soporte oficial, la forma de tu JSON empieza a importar de otra manera, porque el frontend lo vuelca directamente en estado reactivo en lugar de pasarlo por capas de transformaciones hechas a mano. Eso devuelve la presión de diseño a la API. Si tus resource classes de Laravel devuelven una nulabilidad incoherente, o los grupos de serialización de Symfony sueltan un conjunto de campos distinto según la ruta, una interfaz basada en señales va a dejar cada incoherencia a la vista en pantalla. Sinceramente, lo veo como un regalo. PHP lleva una década aprendiendo a hacer APIs tipadas y predecibles; esta es una oportunidad para aprovecharlo.

Angular Aria también merece una mención rápida, ya que llega en la misma release. Tener primitivas accesibles sin estilos impuestos significa que el marcado que tus plantillas Blade o Twig generaban para las páginas renderizadas en servidor y el de la app Angular por fin pueden seguir los mismos patrones de accesibilidad, algo que agradecerá cualquiera que haya tenido que pasar una auditoría sobre las dos mitades de un mismo producto. Y el servidor MCP del CLI es útil por una razón aburrida: puede dirigir a un asistente a la documentación actual en lugar de a lo que absorbió durante su entrenamiento. Lo aburrido está bien. Los de Go lo llamarían idiomático y seguirían a lo suyo.

Así que esto es lo que de verdad me gustaría saber, sobre todo si tienes una API PHP detrás de Angular o de cualquier otro frontend basado en señales: ¿dónde viven hoy tus reglas de validación, y has encontrado una forma de compartirlas entre lenguajes que haya sobrevivido a más de un ciclo de producto? ¿Esquemas generados a partir de atributos PHP, un pipeline de OpenAPI, un endpoint de validación dedicado, o simplemente dos archivos y mucha disciplina? Cuéntame qué se rompió.