Rapid Application Platform

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.

*Hinter dem Begriff „Markdown" steckt hier konkret die in AFM eingeführte Erweiterung MD++: Standard-Markdown plus eine generische Syntax-Schicht (Frontmatter, Annotationen, getypte Code-Blöcke wie Mermaid) plus eine RAP-spezifische Semantik-Schicht (Entity-Definitionen, Computed Columns, ACTION-Links, VIEW- und PROCESS-Vokabular). Die unteren beiden Schichten wären für jedes andere AFT wiederverwendbar; nur die dritte ist RAPs eigene Sprache.*

RAP zielt auf Anwendungen, deren Schwerpunkt die Bearbeitung von Datenbankinhalten ist — Stammdaten, Verträge, Assets, Dispositionsentscheidungen. Excel-ähnliche Ergonomie für die Tabellenarbeit, übersichtliche Navigation, hierarchische Baumdarstellungen, Medienverwaltung, Reports und Import/Export-Schnittstellen gehören "out of the box" dazu. Manche dieser Anwendungen haben zusätzlich einen Rechenkern mit komplexen Algorithmen — Optimierung, Simulation, Bewertung. Solche Code-Teile lassen sich direkt als JavaScript-Modul einbinden oder über REST-APIs an spezialisierte Dienste auslagern.

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.

Werkzeugmacher würden sagen: Es ist eine Maschine, mit der man Maschinen baut.

RAP ist ein konkretes Beispiel für ein Application Flavour Template — den Bauplan einer Software-Familie. Die methodische Sicht darauf, und warum solche Templates der Schlüssel zur erfolgreichen Zusammenarbeit mit KI sind, beschreibe ich im Artikel über Application Flavour Modelling.

Die folgenden Beschreibungen beziehen sich auf eine kleine Demo-Anwendung — eine Schul-Bibliothek mit Büchern, Exemplaren, Schülern, Lehrern, Ausleihen und einem Beschaffungs-Workflow. Sie ist als öffentlich begehbare Live-Demo erreichbar (siehe Reinschnuppern am Ende).

Im Repository messbar:

  • rund 2.400 Zeilen Markdown über neun Entitäten, die zugehörigen Views, Processes und Docs — die deklarative Schicht, aus der RAP zur Laufzeit Datenbank, REST-API und Standard-UI erzeugt
  • acht Benutzer-Aktionen (Ausleihen, Rückgabe, Counter-Workflows mit Barcode-Scanner, Beschaffungs-Vorschlag, Buch-Aufnahme mit ISBN-Scan, Ausweis-Druck) mit zusammen ~3.700 Zeilen JavaScript/CSS/HTML, durchschnittlich ~300 Zeilen JavaScript pro Aktion — kompakt, weil sich die Aktionen auf die REST-Schicht der RAP-Plattform stützen und weder Authentifizierung noch Datenbankzugriff selbst implementieren müssen
  • ~340 Zeilen server-seitiger Custom-Code für drei Helfer-Routen (z.B. PDF-Generierung des Ausweises, Auto-Cover-Download via Open-Library), wo eine Aktion mehr als reines CRUD braucht

Die deklarative Markdown-Schicht ist der Hauptteil; die imperativen Bestandteile entstehen erst dort, wo der konkrete Geschäftsablauf eine eigene Oberfläche oder einen Server-seitigen Hook verlangt.

Die einzelnen Bestandteile sind als eigene Markdown-Dateien gepflegt, deren Aufbau im nächsten Abschnitt erläutert wird.

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 in einem Bild fassen — am besten aus Sicht der Küche. Ein Code-Generator ist wie eine Druckerei, die aus einem Manuskript tausende Seiten Programmcode druckt. RAP ist eher ein Restaurant: Die Markdown-Spezifikation ist die Speisekarte. Beim Start liest der Koch — der Server — sie einmal und merkt sie sich als ein Bild dessen, was das Haus anbieten kann (das Schema); er wirft einen Blick in die Vorratskammer (die Datenbank) und räumt sie um, falls Karte und Bestand nicht mehr zusammenpassen — die Zutaten selbst schafft, mit etwas Vorlauf, der Einkäufer heran (in RAP der IMPORT-Mechanismus). Setzt sich ein Gast — ein Client — an den Tisch, bekommt er einmalig dieselbe Karte in die Hand; von da an genügt »einmal Nummer 12«, und beide wissen sofort, was gemeint ist, weil sie dieselbe Karte teilen. Die Küche interpretiert die Bestellung, greift in die Vorratskammer und serviert die Zeilen als schlichte Feld-Wert-Listen. Das eigentlich Verblüffende steht im Kleingedruckten: Man stellt kein neues Personal für jedes Restaurant ein — dieselbe Küche arbeitet jede Karte ab, die man ihr reicht; eine neue Karte ergibt ein anderes Restaurant, ganz ohne Umbau. (Wer Musik liebt, darf sich RAP auch als Orchester denken, das direkt aus der Partitur spielt — aber eine Speisekarte hatte nun wirklich jeder schon in der Hand.)

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 address expandiert 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. Für sensible Daten kann pro Entität ein 4-Augen-Prinzip aktiviert werden: Änderungen werden dann als Vorschlag erfasst und erst nach Bestätigung durch einen zweiten Berechtigten wirksam — inklusive Sammel-Genehmigung bei Massen-Importen.
  • 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 mö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.

Parallelbetrieb

RAP läuft im Cluster-Betrieb: Mehrere Node-Prozesse — die Worker — teilen sich dieselbe Maschine und bedienen Anfragen parallel. Ein ausgewählter Worker (der Leader) übernimmt einmalig die schemabezogenen Aufgaben beim Start — Migration, Tabellen-Anlage, Seed-Import — die übrigen Worker konzentrieren sich vollständig auf laufende Requests. Bevor ein Worker Anfragen annimmt, wartet er, bis der Leader seine Initialisierung gemeldet hat. Damit sind die typischen Race-Conditions beim Cluster-Start ausgeschlossen.

Das Konzept ist auf Robustheit im Mischbetrieb optimiert. Wenn ein einzelner Request eine länger dauernde Auswertung berechnet, blockiert das genau einen Worker — alle anderen bedienen weiter. Bei acht Workern bleiben somit 87,5 % der Kapazität verfügbar, auch während ein Fachanwender eine schwere Recherche-Query laufen lässt. Andere Nutzer merken davon nichts. Live-Updates zwischen Workern — etwa wenn jemand eine Zeile ändert und Kollegen das sofort in ihrer Tabelle sehen sollen — werden über einen schlanken datenbank-internen Eventbus propagiert.

In einem Lasttest auf einer 8-Kern-Maschine bedienten acht Worker 50 gleichzeitig angemeldete Clients über 60 Sekunden mit über 6.000 authentifizierten Requests — ohne einen einzigen Fehler, bei rund 100 Requests pro Sekunde anhaltender Last und einer Streuung der Worker-Auslastung unter einem Prozent. Diese Größenordnung deckt den typischen Einsatz mit mehreren Dutzend Fachleuten am Bildschirm souverän ab.

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. Durch RAP entsteht für die eigentliche 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.

Wie sich das anfühlt? Lesen Sie ein authentisches Beispiel — eine echte RAP-Genesis, vom Trainer-Gespräch bis zum laufenden System, ehrlich aufgezeichnet.

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 Unternehmens-IT, keine Versionierung

Drei produktive Einsatzszenarien — und eine klare Abgrenzung, wofür RAP nicht gedacht ist:

  • 🗂️ Dispo-Anwendungen. Der Übergang von vielen lose verknüpften Excel-Landschaften zu einer echten Datenbank-Plattform wird mit RAP 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. Typische Domänen: Disposition, Vertragsbearbeitung, Angebotserstellung, Recherche- und Analyse-Arbeitsplätze für mehrere Dutzend Fachanwender im Cluster-Modus.

  • 🔎 Data-Warehouse-Frontend. RAP dient als Read-only-Browser für bestehende Datenbanken. 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.

  • 🌱 KMU-Individuallösungen auf der grünen Wiese. RAP eignet sich auch hervorragend für das Neu-Erstellen kleinerer Anwendungen. Es macht die Versprechungen, die als 4GL vor zwei Jahrzehnten in die Welt gesetzt wurden, endlich wahr — quasi MS-Access auf Steroiden. Eine wichtige Zielgruppe sind daher auch Softwarehäuser, die Individuallösungen für kleine und mittelständische Unternehmen entwickeln. Für genau sie existiert mit rapsmgr bereits eine Konsole, die ganze Flotten von RAP-Systemen über mehrere Hosts betreibt (Start/Stop, Build, Deploy, Status, verschlüsseltes Register) — damit ist zumindest eine technische Grundlage für ein SaaS-Angebot gelegt.

  • 🚫 Nicht für Massive Online Systems — und keine nativen Store-Apps. RAP eignet sich nicht für massiv parallele Online-Buchungssysteme oder soziale Plattformen: Der Cluster-Modus deckt mehrere Dutzend gleichzeitig arbeitende Fachanwender souverän ab, aber Hunderttausende anonyme Web-Besucher sind ein anderes Architektur-Spiel. Und RAP erzeugt keine nativen, im Store ausgelieferten Apps (in Swift/Kotlin ausprogrammiert, ausgeliefert über Google Play / Apple App Store). „Mobil" ist damit aber nicht ausgeschlossen — im Gegenteil: RAP läuft im mobilen Browser, ist als PWA installierbar (Add-to-Homescreen, ohne Store) und nutzt Gerätefunktionen über Web-APIs — die Kamera als Barcode-Scanner (Schul-Bibliothek) und der Foto-Upload vom Handy (Hundeschule) sind gelebte Beweise.

Wie RAP entstanden ist

RAP wurde innerhalb eines Jahres 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.

Für den professionellen Betrieb: Replikation & Mandantenfähigkeit

Zwei Eigenschaften heben RAP von einer Demo-Plattform zu einer, die einen echten Betrieb trägt:

Gerichtete Replikation. Eine kuratierte Quelle wird auf offline-robuste lokale Knoten repliziert — etwa einen kleinen Rechner an einem Wand-Display oder in einer Filiale. Jeder Knoten liest aus seiner eigenen RAP-Instanz und arbeitet weiter, wenn das Netz wegbricht; beim Wiederverbinden holt er sauber auf, ohne etwas zu verlieren oder doppelt anzuwenden. So wird RAP zu einem offline-toleranten Frontend über einem Data-Warehouse.

Mandantenfähigkeit. Eine Plattform trägt viele Mandanten auf demselben Datenmodell und Code — mit von der Engine erzwungener Isolation: Die Mandantengrenze ist ein Spaltentyp, den die Plattform bei jedem Schreibzugriff automatisch stempelt und bei jedem Lesezugriff filtert. Es gibt kein „bloß-nicht-vergessen-zu-filtern"-Risiko; ein mandantenübergreifendes Datenleck ist strukturell unmöglich. Dazu kommen ein bewusst geteilter Gemeinschaftsbereich und gezielte, protokollierte Übergänge dort, wo der Betrieb sie wirklich braucht. Führt eine Gruppe viele lokale Betriebe zusammen, wird eine einheitliche IT-Plattform zum entscheidenden Effizienzhebel.

Beides wurde im selben Arbeitsmodus entworfen und gebaut, der RAP selbst hervorgebracht hat — die Spezifikation bleibt die einzige Quelle der Wahrheit, und das Sicherheitsnetz aus Substrat, Detektoren und Architekten-Veto trägt.

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. Die eigentliche Anwendung benutzt RAP quasi wie einen Interpreter, der keinerlei Kenntnis von fachlichen Inhalten hat.

RAP selbst wird kostenfrei für private und akademische Nutzung zur Verfügung gestellt — für Studierende, Forschungseinrichtungen und private Experimente. Eine kommerzielle Nutzung (intern in Unternehmen oder als Teil eines kommerziellen Produkts) erfordert eine gesonderte Lizenzierung. Das Lizenzmodell ist ein eigenes mit Non-Commercial-Klausel; der Quelltext bleibt zugänglich. Damit ist das Partner-Modell abgesichert, und akademische Welt sowie Privatleute haben gleichzeitig freien Zugang.

Es gab etliche Sicherheitsanalysen von RAP, deren Findings alle Teil des Repositories sind. Ich würde dringend empfehlen, 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.

Reinschnuppern

Wer einen Eindruck von der laufenden Demo bekommen möchte, schreibt mir eine kurze Mail; ich richte gerne einen persönlichen Gast-Zugang zur Schul-Bibliothek ein. Bitte kurz schildern, welcher Aspekt Sie interessiert — dann kann ich gleich auf die passende Stelle der Anwendung verweisen.

Kontakt: Dr. Gero Scholz · gero.scholz@gmail.com