A colleague who maintains a Symfony API with an Angular admin panel sent me a screenshot last week: two files open side by side, a `UserRegistrationType` with eleven constraints on the left and a TypeScript validator on the right with nine of them. Two were missing. Nobody knew which side was correct, and the bug ticket had been open since March. Angular v22 shipped in June 2026, it sits at 22.2.x now, and the stable stamp on Signal Forms is about to make that screenshot a lot more common in PHP shops, unless we decide right now that the PHP side owns the rules.

Some facts so we argue from the same page. Version 22 is a consolidation release. Three APIs that were experimental in v21 are now stable: Signal Forms, the asynchronous signals built around `resource` for loading server data, and Angular Aria, a set of headless accessible primitives. The team also shipped official LLM prompts, an MCP server in the Angular CLI and agent skills. No rewrite, no new mental model. The upgrade itself runs through `ng update` like every year.

So why should a Laravel developer care about a frontend point release? Because stable APIs get adopted by people who previously waited, and in mixed teams the people who waited are usually the backend folks who get roped into frontend tickets on a Thursday afternoon. Signal Forms lets you express validation as ordinary TypeScript functions. That is lovely to write. It is also the fastest route I know to a second, silently diverging copy of every rule you already maintain in a FormRequest or a Symfony constraint, and the drift will not show up in tests because each side tests itself.

My position: treat the PHP backend as the only place a business rule lives, and treat Signal Forms as the renderer of that verdict. Your endpoint already returns a 422 with a structured error bag in Laravel, or a violation list from the Validator component in Symfony. Map those onto form fields, consistently, in one place in the frontend. Client-side checks stay for the trivial cosmetic stuff: a field is empty, an email has no @ in it. Anything involving a database lookup, a tenant setting or a pricing rule gets decided by PHP and displayed by Angular.

The best argument against me is latency and feel. Waiting for a roundtrip to learn that a coupon code has expired feels sluggish next to an instant red border, and on a bad mobile connection 400 ms per field turns a checkout into a chore. Fair. Product people will notice, and they will be right. My answer is that you can debounce a validation endpoint, and that a slow correct message beats a fast wrong one: the fast wrong one is how a customer gets told a code is valid, clicks pay, and opens a support ticket at 23:40 when the server refuses the order anyway. I would rather tune an endpoint than reconcile two rulebooks forever.

The same logic carries over to `resource`. Now that loading server data through signals is officially supported, the shape of your JSON starts to matter in a new way, because the frontend reads it straight into reactive state instead of passing it through layers of hand-rolled transformation. That pushes design pressure back onto the API. If your Laravel resource classes return inconsistent nullability, or your Symfony serializer groups leak a different field set depending on the route, a signal-driven UI will make every inconsistency visible on screen. Honestly I see that as a gift. PHP has spent a decade getting good at typed, predictable APIs; this is a chance to use it.

Angular Aria deserves a quick nod too, since it lands in the same release. Accessible primitives without imposed styling mean the markup your Blade or Twig templates used to render for server-side pages and the markup in the Angular app can finally follow the same accessibility patterns, which helps anyone who has had to pass an audit across both halves of one product. And the CLI MCP server is useful for one boring reason: it can point an assistant at current docs instead of whatever it absorbed during training. Boring is good. Go people would call it idiomatic and move on.

So here is what I would actually like to hear from you, especially if you run a PHP API behind an Angular or any other signal-based frontend: where do your validation rules live today, and have you found a way to share them across the language boundary that survived more than one product cycle? Generated schemas from PHP attributes, an OpenAPI pipeline, a dedicated validate endpoint, or simply two files and a lot of discipline? Tell me what broke.