Ein Kollege, der eine Symfony-API mit einem Angular-Adminpanel betreut, hat mir letzte Woche einen Screenshot geschickt: zwei Dateien nebeneinander, links ein `UserRegistrationType` mit elf Constraints, rechts ein TypeScript-Validator mit neun davon. Zwei fehlten. Niemand wusste, welche Seite recht hatte, und das Bug-Ticket war seit März offen. Angular v22 ist im Juni 2026 erschienen, aktuell steht es bei 22.2.x, und der Stable-Stempel auf Signal Forms wird solche Screenshots in PHP-Shops bald deutlich häufiger machen, es sei denn, wir legen jetzt fest, dass die PHP-Seite die Regeln besitzt.

Ein paar Fakten, damit wir von derselben Grundlage aus streiten. Version 22 ist ein Konsolidierungsrelease. Drei APIs, die in v21 noch experimentell waren, sind jetzt stabil: Signal Forms, die asynchronen Signals rund um `resource` zum Laden von Serverdaten und Angular Aria, eine Sammlung headless, barrierefreier Primitive. Dazu hat das Team offizielle LLM-Prompts, einen MCP-Server in der Angular CLI und Agent Skills ausgeliefert. Kein Rewrite, kein neues mentales Modell. Das Upgrade selbst läuft wie jedes Jahr über `ng update`.

Warum sollte sich also jemand aus der Laravel-Ecke für ein Frontend-Release interessieren? Weil stabile APIs von den Leuten übernommen werden, die bisher abgewartet haben, und in gemischten Teams sind das meist die Backend-Leute, die an einem Donnerstagnachmittag in Frontend-Tickets reingezogen werden. Mit Signal Forms formulierst du Validierung als ganz normale TypeScript-Funktionen. Das schreibt sich wunderbar. Es ist aber auch der schnellste Weg, den ich kenne, zu einer zweiten, still auseinanderlaufenden Kopie jeder Regel, die du schon in einem FormRequest oder einem Symfony-Constraint pflegst, und die Abweichung taucht in keinem Test auf, weil jede Seite nur sich selbst testet.

Meine Position: Behandle das PHP-Backend als den einzigen Ort, an dem eine Geschäftsregel lebt, und Signal Forms als die Darstellung ihres Urteils. Dein Endpoint liefert in Laravel ohnehin schon eine 422 mit strukturiertem Error-Bag, in Symfony eine Violation-Liste aus der Validator-Komponente. Bilde die konsistent auf die Formularfelder ab, an genau einer Stelle im Frontend. Clientseitige Checks bleiben für das triviale Kosmetische: Ein Feld ist leer, eine E-Mail-Adresse hat kein @. Alles, was einen Datenbank-Lookup, eine Mandanteneinstellung oder eine Preisregel braucht, entscheidet PHP, und Angular zeigt es an.

Das beste Gegenargument sind Latenz und Gefühl. Auf einen Roundtrip zu warten, um zu erfahren, dass ein Gutscheincode abgelaufen ist, fühlt sich neben einem sofortigen roten Rahmen zäh an, und bei schlechter Mobilverbindung machen 400 ms pro Feld aus dem Checkout eine Qual. Berechtigt. Die Produktleute werden das merken, und sie werden recht haben. Meine Antwort: Einen Validierungs-Endpoint kannst du debouncen, und eine langsame richtige Meldung schlägt eine schnelle falsche. Die schnelle falsche ist genau die, bei der eine Kundin hört, der Code sei gültig, auf Bezahlen klickt und um 23:40 ein Support-Ticket aufmacht, weil der Server die Bestellung trotzdem ablehnt. Ich tune lieber einen Endpoint, als für immer zwei Regelwerke abzugleichen.

Dieselbe Logik gilt für `resource`. Jetzt, wo das Laden von Serverdaten über Signals offiziell unterstützt wird, zählt die Form deines JSON auf neue Weise, weil das Frontend es direkt in reaktiven State liest, statt es durch Schichten handgebauter Transformationen zu schicken. Das verlagert den Designdruck zurück auf die API. Wenn deine Laravel-Resource-Klassen uneinheitliche Nullability zurückgeben oder deine Symfony-Serializer-Gruppen je nach Route ein anderes Feld-Set durchsickern lassen, macht eine signalgetriebene UI jede Inkonsistenz auf dem Bildschirm sichtbar. Ehrlich gesagt sehe ich das als Geschenk. PHP ist in den letzten zehn Jahren richtig gut in typisierten, vorhersagbaren APIs geworden; das ist die Gelegenheit, das auch auszuspielen.

Angular Aria verdient auch ein kurzes Nicken, weil es im selben Release landet. Barrierefreie Primitive ohne vorgegebenes Styling bedeuten, dass das Markup, das deine Blade- oder Twig-Templates für serverseitige Seiten gerendert haben, und das Markup in der Angular-App endlich denselben Accessibility-Mustern folgen können. Das hilft allen, die schon mal ein Audit über beide Hälften eines Produkts bestehen mussten. Und der MCP-Server in der CLI ist aus einem langweiligen Grund nützlich: Er kann einen Assistenten auf die aktuelle Doku verweisen statt auf das, was der im Training aufgeschnappt hat. Langweilig ist gut. Go-Leute würden es idiomatisch nennen und weitermachen.

Deshalb würde ich gern von dir hören, vor allem wenn du eine PHP-API hinter einem Angular- oder einem anderen signalbasierten Frontend betreibst: Wo leben deine Validierungsregeln heute, und hast du einen Weg gefunden, sie über die Sprachgrenze hinweg zu teilen, der mehr als einen Produktzyklus überlebt hat? Generierte Schemas aus PHP-Attributen, eine OpenAPI-Pipeline, ein eigener Validate-Endpoint oder einfach zwei Dateien und viel Disziplin? Erzähl mir, was kaputtgegangen ist.