In unserer kleinen Serie über flexible, mobile und zukunftssichere Web-Oberflächen für Domino-Anwendungen soll es heute um ein Thema gehen, dass von elementarer Bedeutung für jedes Web-Entwicklungsprojekt ist: Eingabevalidierung und Business-Logik auf der Backend-Seite. Wie wir bereits ausgeführt haben, favorisieren wir bei der Web-Entwicklung eine Trennung zwischen Frontend und Backend.
Bei diesem Konzept werden selbstverständlich die Daten auf der Browser-Seite geprüft, bevor sie via REST-API an den Backend-Server, in unserem Fall bevorzugt der IBM Domino Server, übertragen werden. Allerdings ist diese Prüfung auf der Frontend-Seite nicht ausreichend.
Daten müssen ebenfalls im Backend validiert werden
Es ist existenziell, dass alle zum Server übertragenen Daten im Backend noch einmal auf fachliche Richtigkeit und Vollständigkeit geprüft werden. Der Hauptgrund dafür ist, dass die zur Verfügung gestellte REST-API auch ohne die dafür gedachte Web-Oberfläche benutzt werden kann. Insofern muss sichergestellt werden, dass auch bei direktem Aufruf der REST-API alle Business-Regeln ihre Anwendung finden.
Im ersten Moment mag das doppelten Aufwand bedeuten. Aber es ist ein Aufwand, der sich sowohl für den Anwender als auch für das Unternehmen auszahlt.
Für die Anwender ist die Validierung bereits im Browser sinnvoll, weil unmittelbar bei der Bedienung entsprechende Hinweise gegeben werden können. Die deutliche Hervorhebung, welche Daten fehlen und warum, führt zu einer besseren User Experience (UX) und damit auch zu einer höheren Akzeptanz. Eine Prüfung im Frontend bedeutet auch, dass die Zugriffe auf den Server minimiert werden. Das ist ein Aspekt, der insbesondere bei der mobilen Benutzung wichtig ist. Bei einer schwachen Netzwerkanbindung und dem entsprechend langen Antwortzeiten verlängert jeder unnötige Serverzugriff den Frust auf Anwenderseite.
Im Idealfall bemerkt der Anwender nicht, dass die Daten auf Backend-Seite noch einmal überprüft wurden. Einige Aspekte in einer Anwendung können allerdings nur im Backend geprüft werden. Das beinhaltet z.B. die Prüfung auf Eindeutigkeit oder ob eine Ressource in der Zwischenzeit bereits von jemanden anderen reserviert wurde.
Business-Logik bei REST-APIs
Eingabevalidierung ist ein wichtiger Aspekt im Backend. Aber er ist bei weitem nicht der wichtigste Aspekt. Bei den meisten Anwendungen geht es nicht nur darum, Daten auf einem Server zu speichern. Der Prozess hinter der Anwendung bringt für das Unternehmen den Mehrwert.
REST steht für "REpresentational State Transfer". Der Teil "State" in dem Ausdruck bezieht sich darauf, dass in dieser Architektur der Server keinen Status der Browser-Client-Sitzung speichert ("Statelessness"). Hinter dieser zugegebenermaßen sperrigen Aussage verbirgt sich, dass jeder Aufruf einer REST-API losgelöst von vorherigen Aufrufen betrachtet werden muss.
Somit ergibt sich, dass bei jedem Aufruf alle für den Prozess notwendigen Informationen entweder mitgeliefert oder anhand der Angaben im Aufruf zusammengestellt werden können müssen. Dieser in sich geschlossene Ansatz ergibt faszinierende Möglichkeiten.
Vorhandene REST-APIs können vielfältig eingesetzt werden
Wenn die REST-APIs geschickt designed werden, können sie in mehren Projekten eingesetzt werden. Geradezu klassisch im Unternehmensumfeld sind REST-APIs, die Informationen über Mitarbeiter oder Unternehmensabteilungen zur Verfügung stellen. Einmal entwickelt, können sie nahezu in jedem Projekt eingesetzt werden. Statt die Information an diversen Stellen vorzuhalten, gibt es eine zentrale Anlaufstelle. Caching-Mechanismen in solch zentralen REST-APIs können eine massive Auswirkung auf die Performance haben.
Die Idee, dass alles mit allem irgendwie zusammen hängt, kann mit REST-APIs auf ein ganz anderes Niveau gehoben werden. Nehmen wir an, dass eine REST-API entwickelt wurde, um bei der Urlaubsplanung prüfen zu können, ob es innerhalb eines Teams zu keinen Überschneidungen kommt. Die gleiche REST-API kann in einem anderen Kontext verwendet werden, um z.B. Tickets nur den tatsächlich vorhandenen Mitarbeitern zuweisen zu können.
Statt also große monolithische REST-APIs zu entwickeln, ist es vorteilhaft, kleinere, von einander los gelöste REST-APIs zu entwickeln. Solche REST-APIs werden auch als Microservices bezeichnet.
"Low-Code / No-Code" in einer modernen IT-Infrastruktur
Microservices sind die Voraussetzung für ein zukunftsweisendes Thema, dass Verantwortliche in allen Branchen beschäftigt: "Low-Code" bzw. "No-Code".
Wie bei jedem Thema, über das viele Beteiligte mit unterschiedlichen Hintergründen und Interessen diskutieren, gibt es mehrere mögliche Interpretationen der Begrifflichkeiten. Zunehmend setzt sich folgendes Verständnis durch.
"Low-Code" bezieht sich auf das Zusammenführen von mehreren Prozessen bzw. Prozessschritten durch hauptsächlich nur Konfiguration zu einem neuen Prozess. Dabei bedienen sich IT-Spezialisten an den vorhandenen REST-APIs und legen nur noch die Parameter fest, die als Ausgangsprodukt des einen REST-Services als Eingangsparameter an den nächsten REST-Service übergeben werden. Durch zwischengeschaltete Bedingungen und gegebenenfalls Transformation von Parametern können sich sehr mächtige Konstrukte bei gleichzeitig geringem Ressourceneinsatz ergeben. Geeignete grafische Oberflächen erlauben dieses per Drag & Drop durchzuführen. Weil dabei wenig bis gar nichts programmiert werden muss, ergibt sich der Begriff "Low-Code". Ein Beispiel für ein "Low-Code"-System ist Node-RED.
"No-Code" wiederum richtet sich eher an den Fachanwender. Ziel ist in kürzester Zeit eine kleine Anwendung innerhalb eines Teams oder Projektes zur Verfügung zu stellen. Auch hierbei kommt eine grafische Oberfläche zum Einsatz. Die Eingabe- und Listenelemente werden aus einer Reihe von Komponenten ausgewählt und per Drag & Drop arrangiert und verknüpft. In diesem Kontext werden vorhandene REST-APIs als Quelle für Auswahldialoge oder ähnliches eingesetzt. Eventuell können auch die Angaben aus dem entstandenen Formular an eine REST-API übergeben werden. Die IBM und HCL haben gerade auf der Engage Konferenz angekündigt, an einem solchen "No-Code"-System für IBM Domino zu arbeiten.
Die beiden Ansätze gewinnen ihre Bedeutung aus der Flexibilität, mit der ein Unternehmen schnell eine Anwendung zur Verfügung stellen kann, um auf eine geänderte Marktsituation reagieren zu können.
