© Excellent backgrounds/Shutterstock.com
Funktionsweise und Aufbau des REST-Servers

JSON-Backend mit Structr und Neo4j


Die quelloffene Software Structr basiert auf der Graphdatenbank Neo4j. Sie erleichtert das Erstellen mobiler und Webanwendungen enorm, da sie einen JSON-/REST-Server mitbringt, der bidirektionale Transformationen zwischen Graphstrukturen und JSON-­Dokumenten ermöglicht. Zudem lässt sie sich über einen grafischen Schemaeditor ohne Programmierkenntnisse konfigurieren.

Im ersten Teil dieser Artikelserie haben wir Structr vorgestellt und die konzeptionellen Grundlagen sowie den Java-Kern näher beleuchtet. Dieser Artikel widmet sich schwerpunktmäßig dem JSON-/REST-Server. Dieser ist auch die Basis für die grafische Benutzeroberfläche, mit der sich der dritte Teil der Serie beschäftigen wird.

Das Besondere am REST-Backend von Structr ist, dass Neo4j damit zur vollwertigen JSON-Dokumentendatenbank wird, die sich als Unterbau für Frontend-Projekte jeglicher Art eignet. Structr verbindet dabei die Vorteile von dokumentenorientierten Datenbanken mit denen einer Graphdatenbank. Grundlage dafür ist die bidirektionale Abbildung von JSON-Dokumenten auf Graphstrukturen in der Datenbank.

Vorteile von Dokumenten- und Graphdatenbanken vereint

Dokumentenorientierte Datenbanken wie z. B. CouchDB oder MongoDB speichern Daten in Form von Dokumenten, die üblicherweise JSON, XML oder Binärdaten enthalten. Man bezeichnet dies auch als semistrukturierte Form, da die Informationen innerhalb eines Dokuments in der Regel nicht weiter strukturiert sind und keinem festen Schema unterliegen. Man könnte auch sagen, dass die Unterstruktur der Dokumente nicht der Datenbankkontrolle unterliegt.

Dokumentenorientierte Datenbanken sind in der Regel schemalos. Das hat den Vorteil, dass man sich um das Datenmodell zunächst keine Gedanken machen muss, denn es ist denkbar einfach: Ein Dokument erhält bei der Speicherung eine eindeutige ID und kann über diese wieder abgerufen werden. Die im Dokument enthaltenen Daten können direkt und als Ganzes verwendet werden. So kann z. B. im Fall von JSON aus dem Dokumentinhalt mithilfe eines JSON-Parsers ein JavaScript-Objekt erzeugt werden.

Gerade bei Frontend-getriebener Anwendungsentwicklung ergibt sich die Datenstruktur für die einzelnen Dokumenttypen mehr oder weniger direkt aus dem Datenmodell der Anwendungsoberfläche und deren für Ein- und Ausgabe verwendeten Elementen wie z. B. Formulare oder Tabellen. Ähnlich verhält es sich bei der Entwicklung auf Basis moderner Client-JavaScript-Frameworks: Dort werden die Daten in Form von JSON-Objekten vorgehalten und können in einer dokumentenorientierten Datenbank direkt und ohne weitere Transformation persistiert werden, z. B. durch Serialisierung in eine Zeichenkette oder Speicherung in einem binären Format wie BSON [1].

Dokumentenorientierte Datenbanken sind einfach anzuwenden

Die Einfachheit bei der Anwendung ist einer der Hauptgründe für die Beliebtheit und den Erfolg aktueller Dokumentendatenbanken. Allerdings zeigen sich mit zunehmender Komplexität des Datenmodells auch Nachteile. Zum einen ist die Abfrage über die Dokumenten-ID allein meist nicht ausreichend, da man Dokumente auch über deren Eigenschaften finden möchte. Dies erfordert eine zusätzliche Indizierung, die in der Regel über textbasierte Indexframeworks erfolgt.

Zum anderen besteht oft der Wunsch, die Struktur der gespeicherten Dokumente zu definieren, zu typisieren und auf Basis der Typzuordnung Regeln und Einschränkungen (Constraints) festzuschreiben. Außerdem möchte man Daten möglichst redundanzfrei abbilden, um die Dokumente nicht unnötig groß werden zu lassen und vor allem Änderungen an Datenobjekten nicht mehrfach in der Datenbank propagieren zu müssen, wo sie referenziert werden. Das erreicht man durch Normalisierung [2], d. h. Zerlegung und Aufteilung in Entitäten, die so weit wie möglich redundanzfrei sind. Diese Zusammenhänge, auch Relationen genannt, bilden zusammen mit den Constraints ein Schema und sind gewollte Abhängigkeiten im Datenmodell, die einem als Entwickler die Erhaltung der Konsistenz und Vermeidung der Redundanz stark erleichtern.

Relationale Datenbanken bringen hier viele praktische Funktionen wie Constraints und Trigger mit, die in dokumentenorientierten Datenbanken meist nicht vorhanden sind oder zusätzlichen Aufwand erfordern. Graphdatenbanken sind durch ihr flexibles Schema gegenüber Dokumentendatenbanken zunächst nicht unbedingt im Vorteil, was die Einhaltung von Schemaregeln angeht. Graphdatenbanken spielen ihre Stärken allerdings bei der Abbildung von Relationen aus. Diese werden als Instanzen (oft engl. Relationship) bereits beim Einfügen von Daten angelegt und sind bei der Abfrage über das sehr schnelle Verfolgen von Beziehungen (engl. Traversal) verfügbar.

Die Besonderheit von Structr ist, dass auch komplexe (JSON-)Objekte mit verschachtelten Datenstrukturen nicht als ein einzelnes Dokument, sondern in Graphstrukturen aufgespalten und mit einem hohen Normalisierungsgrad persistiert werden. Die Denormalisation, d. h....

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang