Frontend von APEX entkoppeln — APEX als Headless-API-Backend
Diese Vorlage prüft, ob das KOMO-Frontend vom APEX-Rendering gelöst und Oracle APEX künftig nur noch als Daten- und API-Backend genutzt werden kann — und wägt ab, warum das gegenüber „alles in APEX" die bessere Wahl sein könnte. Begleitend zur Analyse „Custom-Theme in APEX" (siehe APEX-THEME-FEASIBILITY.md).
Die Optionen im Überblick
Drei grundsätzliche Wege, das gewünschte Erscheinungsbild (dieser Prototyp) in Produktion zu bringen:
| Kriterium | A · In APEX bleiben Universal Theme reskinnen |
B · Entkoppeln Headless-Backend + eigenes Frontend |
|---|---|---|
| UI-Technologie | An APEX / Universal Theme gebunden | Frei wählbar (React, Vue, Web Components …) |
| UX-Detailkontrolle | Über CSS-Variablen & Template-Optionen — bei Sonderfällen „gegen das Framework" | Vollständig — Markup, Verhalten, Fokus-States selbst bestimmt |
| Dieses Design-System | Muss auf APEX-Klassen übersetzt/übersteuert werden | Läuft praktisch unverändert weiter (ist bereits fertig) |
| Time-to-first (Standard-CRUD) | Sehr schnell — APEX Low-Code (Formulare, Reports out of the box) | Langsamer initial — UI ist echte Entwicklungsarbeit |
| API-Wiederverwendung | Gering — UI & Daten eng gekoppelt | Hoch — dieselbe API für Web, Mobile, Portale, Partner |
| Team / Skills | APEX-Spezialwissen nötig | Verbreitete Web-Skills fürs Frontend; DB-Team bleibt bei DB/PL-SQL |
| Initialer Aufwand | Niedrig | Höher (Frontend + API-Layer + Auth) |
Nicht in der Tabelle: „Prototyp so lassen" ist keine Option — die hier gezeigten Seiten sind statische Mockups ohne Daten, Auth oder Persistenz.
Warum Entkopplung — die Argumente
Kein Technologie-Lock-in
Die UI ist nicht mehr an APEX' Rendering gebunden. Frontend-Stack, Bibliotheken und Update-Zyklen werden frei wählbar und unabhängig vom Datenbank-Release.
Das Design-System ist bereits fertig
Dieser Prototyp — Tokens, Komponenten, Interaktionen — ist die produktionsnahe Basis. Entkoppelt läuft er praktisch unverändert weiter; in APEX müsste er auf Framework-Klassen übersetzt und teils übersteuert werden.
Volle UX-Kontrolle
Die Detailpolitur aus diesem Review — konsistente Fokus-States, Offcanvas-Navigation, Custom-Select, durchgängige Tokens — ist im eigenen Frontend selbstverständlich; in Universal Theme ist Vergleichbares teils Aufwand gegen Framework-Vorgaben.
Eine API, viele Kanäle
Dieselben ORDS-REST-Endpunkte bedienen künftig Web-Frontend, eine mögliche Mobile-App, ein Bürger-/Einrichtungsportal und Partner-Integrationen — statt Logik pro Kanal zu duplizieren.
Barrierefreiheit gezielt steuerbar
Für die öffentliche Verwaltung (WCAG 2.1 AA / BITV) ist volle Kontrolle über Markup und ARIA relevant. Im eigenen Frontend wird Barrierefreiheit direkt gestaltet statt aus Framework-Vorgaben abgeleitet.
Unabhängige Deployments & Tests
Frontend und Backend werden separat gebaut, getestet und ausgerollt. Klare Verantwortungstrennung, kleinere Releases, weniger Risiko pro Deployment.
Ehrlich betrachtet — was das kostet
Eine belastbare Entscheidung braucht beide Seiten. Entkopplung bringt Freiheit, aber gibt APEX-Stärken auf, die dann selbst verantwortet werden müssen:
Der Gewinn
- Freie, moderne Frontend-Technologie ohne Framework-Lock-in
- Dieses Design-System bleibt 1:1 nutzbar
- Wiederverwendbare API für weitere Kanäle
- Frontend mit gängigen Web-Skills besetzbar
- Unabhängige, risikoärmere Deployments
Der Preis
- APEX' Low-Code-Tempo für Formulare/Reports entfällt — UI wird echte Entwicklung
- Auth, Session & Autorisierung selbst verantworten (via ORDS OAuth2 + Identity-Provider)
- Reiche Standard-Komponenten (Interactive Grid/Report: Sortierung, Filter, Export) im Frontend nachbauen
- Mehr Infrastruktur: Build-Pipeline, Hosting, CI/CD, Monitoring fürs Frontend
- Dauerhaft zwei Kompetenzfelder: DB/PL-SQL/ORDS und Frontend
Zielarchitektur
Die Datenbank und die Geschäftslogik bleiben, wo sie sind. ORDS stellt sie als API bereit. Das neue Frontend und bestehende APEX-Apps nutzen dieselbe Basis — Ablösung schrittweise, nicht auf einen Schlag.
Migrationspfad — schrittweise, nicht „big bang"
Entkopplung ist kein Alles-oder-Nichts. Ein eigenständiges Frontend und klassische APEX-Apps können auf derselben Datenbank/ORDS-Instanz koexistieren („Strangler-Fig"): Neues und Überarbeitetes entsteht im neuen Frontend, Bestehendes läuft weiter, bis es abgelöst ist.
- ORDS-Spike für eine Entität. Z. B. Einrichtung/Stammdaten als REST-Ressource bereitstellen (auto-REST oder handgeschriebenes Ressourcenmodul) — Machbarkeit & Aufwand real messen.
- Auth-Konzept festlegen. ORDS OAuth2 / Identity-Provider — wie sich das neue Frontend anmeldet und autorisiert (Rollen, Privilegien).
- Ein echter Screen gegen echte API. „Stammdaten bearbeiten" (Buttons, Tabs, Cards, Select, Radios) mit diesem Design-System gegen die ORDS-Endpunkte — Ende-zu-Ende.
- Aufwand & Kosten quantifizieren. Aus dem Spike belastbare Zahlen ableiten und die Vollausbau-Entscheidung fundiert treffen.
Empfehlung
Entkoppeln — aber schrittweise. Der ORDS-REST-Layer wird auf der bestehenden Datenbank aufgebaut; neue und überarbeitete Screens (beginnend mit den hier gestalteten) entstehen als eigenständiges Frontend auf Basis dieses Design-Systems; bestehende APEX-Apps laufen parallel weiter, bis sie abgelöst sind.
Der höhere Anfangsaufwand ist real und im Abschnitt „Was das kostet" offen benannt — er kauft langfristige Unabhängigkeit von UI-Technologie, volle UX-/Barrierefreiheits-Kontrolle und eine wiederverwendbare API. Für ein langlebiges Verwaltungssystem mit hohen UI-/Accessibility-Ansprüchen überwiegt dieser Nutzen. Die Entscheidung sollte jedoch erst nach dem Spike (Schritt 1–3) mit belastbaren Zahlen final getroffen werden.
APEX-THEME-FEASIBILITY.md im selben Ordner. Dieses Dokument ist eine Entscheidungsvorlage (Analyse & Empfehlung), keine Implementierung. Nächster konkreter Schritt ist der ORDS-Spike (Schritt 1). Stand Juli 2026, Entwurf.