Die Frage, die bei jedem Kickoff kommt
Bei 23 unserer letzten 30 Migrations-Kickoffs hat ein Plattformarchitekt innerhalb der ersten Stunde dieselbe Frage gestellt: „Wird das neue System GraphQL bereitstellen?” Die Antwort ist nein — und die Begründung ist jedes Mal dieselbe. GraphQL passt gut zu manchen Problemen. Oracle Forms-Migration gehört nicht dazu.
Dieser Beitrag legt dar, warum, basierend auf unseren Messungen über 14 Produktivbereitstellungen.
Wie das Quellsystem tatsächlich aussieht
Eine Oracle Forms-Anwendung ist eine Sammlung von Bildschirmmasken, von denen jede an eine kleine Anzahl von Datenbankblöcken gebunden ist. Ein Block bildet eine Tabelle oder View ab. Abfragen sind parametrisiert, Ergebnismengen begrenzt, und die Navigation zwischen Masken übergibt eine Handvoll Schlüssel. Das Zugriffsmuster ist eng, vorhersehbar und bereits in den originalen .fmb-Dateien beschrieben.
Die mediane Bildschirmmaske in unserer Stichprobe greift auf 2,3 Tabellen zu und führt 4 verschiedene Abfragen aus. Das 95. Perzentil erreicht 11 Tabellen und 19 Abfragen. Dies ist keine Domäne, in der Clients beliebige Graphen spontan zusammensetzen müssen.
REST bildet die bestehende Struktur ab
Jeder Block, Trigger und jede LOV in einem migrierten Formular hat ein direktes REST-Äquivalent:
GET /api/orders?status=open®ion=EU
GET /api/orders/{id}
POST /api/orders
PATCH /api/orders/{id}
POST /api/orders/{id}/approve
GET /api/lov/customers?q=acm
Der Generator erzeugt einen Endpunkt pro Block-Abfrage, einen pro LOV und einen pro benannter PL/SQL-Aktion. Die OpenAPI-Spezifikation ergibt sich automatisch aus dem JSON-Deskriptor. Jeder Endpunkt ist durchgehend typisiert, weil die Typen aus dem originalen Datenbankschema stammen, nicht aus einer handgeschriebenen Resolver-Schicht.
Die GraphQL-Kosten, über die niemand spricht
GraphQLs Reiz liegt in der Flexibilität. Clients fragen genau die Felder ab, die sie brauchen, Joins passieren serverseitig, und Over-Fetching verschwindet. Für eine Migration zeigen sich diese Vorteile als Kosten:
- N+1-Auflösung. Forms-Bildschirmmasken führen vorhersehbare Joins aus. GraphQL-Resolver müssen diese Joins zur Laufzeit rekonstruieren, und DataLoader-Batching fügt eine Schicht hinzu, die im Quellsystem nicht existierte.
- Autorisierungsoberfläche. SOX-relevante Anwendungen benötigen Zugriffskontrolle auf Feldebene. REST-Endpunkte kodieren Berechtigungen auf Route-Ebene; GraphQL verlagert sie in jeden Resolver. Wir haben eine 3,2-fache Zunahme des autorisierungsbezogenen Codes in einem prototypischen GraphQL-Port gemessen.
- Abfragekomplexitätslimits. Produktive GraphQL-Server benötigen Tiefenlimits, Kostenanalyse und Persisted Queries, um Missbrauch zu verhindern. Nichts davon wird für eine bekannte Menge migrierter Bildschirmmasken benötigt.
- Caching. REST-Antworten cachen sauber auf CDN- und Browser-Ebene. GraphQL-POST-Bodies nicht.
Das Audit-Argument
Oracle Forms-Migrationen fallen häufig unter SOX, HIPAA oder ähnliche Regelwerke. Auditoren prüfen API-Oberflächen. Eine REST API mit 240 Endpunkten und einer OpenAPI-Spezifikation kann an einem Tag durchgegangen werden. Ein GraphQL-Schema mit 80 Typen und beliebiger Abfragekomposition braucht eine Woche — und der Auditor hat immer noch Fragen dazu, welche Client-Abfragen in der Produktion tatsächlich möglich sind.
Bei einer Migrations eines Energieversorgers bat das Audit-Team ausdrücklich um REST, weil ihre bestehende Kontrollmatrix auf HTTP-Verben und URL-Mustern aufgebaut war. Sie für GraphQL umzubauen hätte die SOX-Freigabe um ein Quartal verzögert.
Wann GraphQL sinnvoll wäre
Wir sind nicht dogmatisch in dieser Frage. GraphQL passt gut, wenn Clients heterogen sind, das Schema breit ist und Abfragemuster unvorhersehbar sind — etwa mobile Apps, die aus einem Produktkatalog ziehen. Oracle Forms-Migrationen sind nichts davon. Die Clients sind bekannt (die migrierten Bildschirmmasken), das Schema ist begrenzt (die Datenbank, die die Forms-Anwendung bereits nutzt), und die Abfragen sind in den .fmb-Dateien selbst aufgezählt.
REST hier zu wählen ist kein Konservatismus. Es ist die Passung des Werkzeugs zur Form des Problems.
Die Kernaussage
Jeder Endpunkt in unserem generierten Stack ist REST, in OpenAPI dokumentiert und direkt aus den originalen Forms-Metadaten abgeleitet. Die Entscheidung dreht sich nicht darum, welcher API-Stil abstrakt besser ist. Es geht darum, welcher sauber auf 30 Jahre bildschirmgebundenen Datenbankzugriff abbildet und welcher von Auditoren abgenommen werden kann, bevor die erste Bildschirmmaske live geht.