Was ist RAP?
Die RAP (Rapid Application Platform) erzeugt aus Textspezifikationen vollständige, lauffähige Anwendungen — mit Datenbank, REST-API und Web-Oberfläche. Die Spezifikation wird in Markdown geschrieben: Sie definiert in einfacher Syntax Entitäten, Attribute, Datentypen, Constraints und Beziehungen. Annotationen fügen Details hinzu, wie etwa Default-Werte oder Farbcodes. Komplexe Views, grafische Auswertungen und auch Daten-Importe werden in ähnlicher Weise spezifiziert. Aus dem fertigen Markdown-Text entsteht ohne weiteres Zutun eine Anwendung, die man sofort benutzen kann.
Das Besondere: Die Spezifikation ist gleichzeitig die Dokumentation und das laufende System. Eine einzige Quelle der Wahrheit, keine Übersetzungsfehler, keine Drift zwischen Doku und Code.
Nicht noch ein Code-Generator
Herkömmliche Code-Generatoren — ob aus UML-Diagrammen, GUI-Buildern oder YAML-Schemata — erzeugen für jede Entität vollständigen Quellcode: Datenbankskripte, API-Routen, Formulare, Validierungslogik. Tausende Zeilen pro Tabelle, die nicht selten später von Hand angepasst werden. Die generierte Codebasis wird schnell unüberschaubar und divergiert unweigerlich von der ursprünglichen Spezifikation. Im Grunde sind es Template-basierte Code-Expandierer.
RAP geht einen fundamental anderen Weg: Es gibt keinen generierten Code. Die Markdown-Spezifikation wird zur Laufzeit interpretiert. Die RAP-Engine liest die Beschreibung der Entitäten und erzeugt daraus Definitionen für Datenbanktabellen, Foreign Keys und Indizes, API-Endpunkte und UI-Formulare. Ändert man die Spezifikation, ändert sich das System — ohne Neukompilierung, ohne Code-Merge, ohne manuelles Nachziehen. Das ist ein sehr großer Vorteil während der Entwicklungsphase, erfordert aber natürlich rigide Kontrolle im Produktivbetrieb.
Der Unterschied lässt sich so zusammenfassen: Ein Code-Generator ist wie eine Druckerei, die aus einem Manuskript tausende Seiten Programmcode druckt. RAP ist eher wie ein Orchester, das direkt von der Partitur spielt.
Was steckt in einer Spezifikation?
Eine RAP-Anwendung besteht aus Markdown-Dateien in einer definierten Verzeichnisstruktur:
- Entitäten — Jede Entität ist eine Markdown-Datei mit einer Attribut-Tabelle. Datentypen, Pflichtfelder, Eindeutigkeitsregeln, Wertebereiche und Fremdschlüssel werden durch Annotationen direkt in der Tabelle ausgedrückt.
- Eigene Datentypen — Enumerationen, Pattern-Typen (z.B. Seriennummern), zusammengesetzte Typen sind möglich (eine
addressexpandiert automatisch zu Straße, PLZ, Ort, Land). - Views — Verknüpfungen über mehrere Entitäten mit Dot-Notation für Fremdschlüssel-Pfade. Das entspricht SQL-Joins, wird aber in lesbarer Markdown-Syntax formuliert. In besonders komplexen Fällen kann man auch SQL direkt notieren.
- Prozesse — Mehrstufige geführte Arbeitsabläufe, bei denen jeder Schritt Kontext akkumuliert und an den nächsten weitergibt.
- Importe — Die Datenversorgung aus Nachbarsystemen wird ebenfalls deklarativ in Markdown beschrieben: Quell-Datei, (Excel-)Sheet, Spaltenmapping, Typumwandlung, Filter und unscharfe Zuordnung von Referenzen. So lassen sich Excel-Exporte aus SAP, Fachabteilungen oder von externen Partnern systematisch in die Anwendung überführen — ohne eine Zeile Importcode zu schreiben. Auch eine Messagebus-Anbindung ist möglich.
- Validierung — Feld- und Objekt-Regeln, die isomorph auf Client und Server laufen. Was im Browser als Sofort-Feedback erscheint, wird serverseitig als Integritätsgarantie erzwungen.
- Professionelle Bearbeitung — Optimistic Concurrency Control (OCC) verhindert, dass gleichzeitige Änderungen sich gegenseitig überschreiben. Fehlende Referenz-Objekte können in-situ angelegt werden, ohne den aktuellen Bearbeitungskontext zu verlassen. Alle Änderungen werden in einem Audit Trail lückenlos protokolliert — wer hat wann was geändert.
- Medienverwaltung — Bilder, Dokumente und andere Dateien sind mit HAsh-Pfaden im Dateisystem des Servers definierbar und können als eigener Datentyp (
media) in Entitäten integriert werden, mit konfigurierbaren MIME-Typ-Einschränkungen, Größenlimits und Vorschauanzeige direkt in der Oberfläche (soweit technisch nmöglich).
Visualisierung
RAP bietet vielfältige grafische Darstellungsformen, die alle aus der Markdown-Spezifikation heraus konfiguriert werden:
- Tabellenansichten — sortier- und filterbare Übersichten mit farblicher Hervorhebung
- Baumnavigation — hierarchische Darstellung von Entitäten mit Eltern-Kind-Beziehungen, dynamisch erweiterbar
- Diagramme — Balken-, Linien-, Kreis- und Streudiagramme, direkt aus View-Definitionen erzeugt
- Kartenansichten — Leaflet-Karten für Entitäten mit Geo-Koordinaten, z.B. Standorte von Kunden, Subsidiaries oder Assets
- Matrix-Views — Kreuztabellen, etwa für Kompatibilitätsmatrizen zwischen Asset-Typen
- Formulare — automatisch generierte Eingabemasken mit kontextsensitiver Validierung
All diese Darstellungen entstehen aus denselben Spezifikationsdateien. Der Entwickler wählt die Visualisierungsform; RAP erzeugt die Darstellung.
Der Hebel
Eine mittelgroße Anwendung mit 40 Datenbanktabellen, komplexen Views, Import-Pipelines und geführten Prozessen lässt sich in ca. 10.000 Zeilen Markdown spezifizieren. Die RAP-Engine selbst ist deutlich größer und interpretiert diese Spezifikation. Eine äquivalente handcodierte Anwendung würde leicht 150.000 Zeilen erreichen. Druch RAP entsteht für die eigebntliuche Anwendung ein beachtlicher Hebelfaktor, denn man muss die RAP-Engine nicht verstehen, um damit eine Anwendung zu bauen.
Und weil die Spezifikation reiner Text ist, gelten alle Vorteile, die Unix-Entwickler seit Jahrzehnten schätzen: grep, diff, sed, Versionskontrolle mit sprechenden Diffs, und — nicht zuletzt — können AI-Agenten die Spezifikation lesen, verstehen und erzeugen. In manchen Fällen kann man sogar den Nukleus einer RAP-Anwendung im Dialog mit einer KI erstellen lassen. Dies ist der essentielle Vorteil von RAP gegenüber sämtlichen Click-Build-Tools.
Es genügen buchstäblich 10 oder zwanzig Sätze über eine fachliche Domäne, um ein initiales Modell und damit eine erste, ausführbare Anwendung zu erstellen.
Für wen?
RAP beruht auf einer relativ konservativen JS – Architektur (mit ein wenig TypeScript) auf Client und Server und nutzt eine Datenbank, die hochgradig auf Lesezugriffe optimiert ist.
Daraus ergeben sich bestimmte Randbedingungen für die Nutzung von RAP basierten Systemen.
RAP-Anwendungen zielen typischerweise auf Fachleute, die vor mehreren Monitoren sitzen, sich in einer komplexen Datenlandschaft unter wechselnden Perspektiven einen Überblick verschaffen müssen, um dann kluge Entscheidungen zu treffen. Typische Ausgangs-Konstellation:
- Mittelgroße Teams hinter der Enterprise-Firewall
- Komplexe Daten, die heute in ambitionierten Excel-Landschaften verwaltet werden
- Abhängigkeit von Schlüsselpersonen, schwache Integration in die Untermehmens-IT, keine Versionierung
RAP macht den Übergang von vielen lose verknüpften Excel-Anwendungen zu einer echten Datenbank-Plattform risikoarm: Schon nach wenigen Tagen existiert ein lauffähiger Prototyp mit realistischen Daten, an dem Fachleute sofort mitgestalten können — nicht anhand von Spezifikationsdokumenten, sondern am lebenden System.
Ein zweites Einsatzszenario: RAP kann auch als Read-only-Browser für bestehende Datenbanken dienen. Man importiert einmalig das Schema und dann periodisch die Daten — täglich, stündlich oder nahezu in Echtzeit via Database-Log-Sniffing — und nutzt RAP als ergonomisches Frontend — mit Views, Diagrammen, Karten und Filtern. Quasi ein besonders komfortables UI für eine Art Data Warehouse, ohne in die Quelldatenbank einzugreifen. Dieser Ansatz kann das Kosten-Nutzen-Verhältnis von MS-Power-Tools deutlich unterbieten.
RAP eignet sich nicht für massiv parallele Buchungssysteme, soziale Plattformen oder mobile Apps. Es geht um datennahe Dispositionssysteme oder Vertragsbearbeitung, Angebotserstellung usw., bei denen Recherche, Analyse und sorgfältige Entscheidung im Vordergrund stehen.
Wie RAP entstanden ist
RAP wurde vollständig mit Agentic Coding entwickelt. Die klassische Schätzung für ein vergleichbares System liegt bei mindestens zehn Personenjahren. Das System selbst ist damit ein Beleg für die Produktivitätsgewinne, die AI-gestützte Entwicklung ermöglicht.
Mehr über den Entstehungsprozess und die Erfahrungen mit Agentic Coding steht auf der Startseite dieses Webauftritts.
Wie geht es weiter?
Ich suche Partner, die den Wert der RAP-Plattform erkennen und eine passende fachliche Problemstellung mitbringen. Der jeweilige Partner erwirbt alle Rechte an seiner spezifischen Anwendung — also an den anwendungsspezifischen Markdown-Dokumenten. RAP selbst allerdings wird mittelfristig als Open Source (MIT-Lizenz) veröffentlicht werden. Dies sichert die Partner am besten ab und erlaubt der akademischen Welt freie Nutzung. Die eigentliche Anwendung benutzt RAP quasi wie einen Interpreter, der keinerlei Kenntnis von fachlichen Inhalten hat.
Es gab etliche Sicherheitsanalysen von RAP, deren Findings alle Teil des Repositories sind. Ich würde dringend enpfehlen, dass Änderungen an RAP mit größter Sorgfalt erfolgen. Die Evolution von RAP zeigt, dass beim Bau einer neuen App inzwischen 90% der Energie in die eigentliche Anwendung fließen. Sporadisch kommt es vor, dass man sich ein bestimmtes Feature wünscht, das von seinem Wesen her in RAP verankert werden sollte. Es ist in so einem Fall sogar möglich, private Forks von RAP zu machen, die keiner Publikationspflicht unterliegen. Die einzige zusätzliche Einschränkung, die mein Open Source Lizenz Modell gegenüber der originalen MIT Lizenz macht, besteht darin, dass RAP oder ein modifiziertes RAP niemals kommerziell verwertet werden darf.
Reinschnuppern
Eine kleine Demo-Anwendung vermittelt einen Eindruck davon, wie sich RAP anfühlt. Es handelt sich um ein Spielbeispiel mit fiktiven Daten, das einzelne Features demonstriert — nicht um eine produktive Anwendung:
Anmeldung als gast mit dem Passwort guest. Unter dem Menüpunkt „Prozess auswählen" → „Explore Sunergy" finden Sie ein geführtes Tutorial. Ein Doppelklick auf die Zeile, die nach der Auswahl erscheint, öffnet den Prozess.
Kontakt: Dr. Gero Scholz · gero.scholz@gmail.com