Übersicht

Ich habe etwa vier Jahre lang hauptsächlich mit RDBMS entwickelt und war auch in der Produktionsumgebung größtenteils mit AWS RDS vertraut. Als ich ein neues persönliches Projekt startete, wählte ich MongoDB zum ersten Mal und stellte fest, dass es nicht nur eine Datenbank mit flexibler Schema war, sondern ein Werkzeug, das meine Entwicklungsproduktivität erheblich verändern könnte.

Insbesondere MongoDB Atlas war für mich eine neue Welt. Ich konnte professionelle Suche und Vektorsuche, von denen ich dachte, dass ich separate Systeme anschließen müsste, innerhalb einer einzigen Datenplattform nutzen, und Betriebsaufgaben wie Backup, Monitoring und Skalierung waren für mich, der nur mit AWS RDS gearbeitet hatte, viel bequemer. Wenn ich eine professionellere Skalierung und Funktionalität benötige, könnte ich Suchmaschinen oder Vektordatenbanken als separate Dienste trennen, aber in der Phase, in der ich ein Projekt schnell erstellen und betreiben wollte, war der Umfang, den ich mit Atlas lösen konnte, sehr attraktiv.

Das Problem war, dass es für mich als Neuling in MongoDB zu langsam war, dynamische Abfragen zu schreiben. Zunächst war die findBy...-Form des Repositories ausreichend, aber als die Suchbedingungen komplexer wurden, musste ich Query, Criteria und Operatoren manuell zusammenstellen. In einem ungewohnten Zustand war es leicht, Tippfehler zu machen, und das ständige Schreiben ähnlicher Codes verlangsamte die Entwicklung erheblich.

Deshalb war das erste, was ich machte, eine kleine Klasse, um nur das R von CRUD einfach zu erstellen. Dies war der Ausgangspunkt der Klasse, die heute als ReactiveMongoDsl bekannt ist. Zu dieser Zeit gab es keine Funktionen wie Aggregation, Pipeline oder Lookup, und es ging nur darum, die Query, Criteria und Paging von Spring Data ReactiveMongoTemplate etwas schneller zusammenzustellen. Ich dachte, dass die restlichen Aufgaben mit dem grundlegenden ReactiveMongoTemplate oder dem MongoDB Driver ausreichend erledigt werden könnten.

Aber die Meinung eines Entwicklers, mit dem ich zusammenarbeitete, war anders. Auch er war neu in MongoDB und fragte jedes Mal, wenn er Funktionen wie Upsert oder Bulk benötigte, ob diese in der DSL, die ich erstellt hatte, vorhanden waren. Ich hätte ihm sagen können, dass er die grundlegenden APIs direkt verwenden soll, aber ich dachte, dass er die gleichen Schwierigkeiten haben würde, die ich beim ersten Lernen von MongoDB hatte. Also begann ich, nach und nach die benötigten Funktionen in die ReactiveMongoDsl hinzuzufügen.

Anfangs hatte es etwa 600 Zeilen, und als es 1.000 Zeilen erreichte, dachte ich nicht, dass es notwendig sei, es in mehrere Klassen zu unterteilen. Als es etwa 2.000 Zeilen hatte, überlegte ich ein wenig, aber die Struktur zur Trennung fühlte sich eher größer an, und vor allem war ich ehrlich gesagt zu faul für diese Arbeit. Als es 5.000 Zeilen überschritt, konnte ich es nicht länger aufschieben und verschob einige trennbare Funktionen nach außen, aber es war bereits eine große Belastung, den Kernfluss detailliert neu zu unterteilen. Der Grund, warum die Kernklasse so groß ist, liegt nicht daran, dass ich von Anfang an eine riesige DSL entworfen habe, sondern vielmehr an der Geschichte, dass ich die Funktionen, die in echten Projekten benötigt wurden, immer wieder am gleichen Einstiegspunkt hinzugefügt habe.

Nachdem ich Funktionen wie Abfragen, Aggregationen, Lookups, atomare Updates, Bulk, Historie, Atlas Search und Vektor-Suche hinzugefügt hatte, stellte ich fest, dass die meisten Funktionen, die ich häufig benötigte, beim Arbeiten mit MongoDB in Java-Projekten bereits enthalten waren. Anstatt sie nur als interne Hilfsfunktionen in einem Projekt zu belassen, trennte ich sie, damit sie in mehreren Projekten auf die gleiche Weise verwendet werden konnten, und das ist der Entstehungsprozess von reactive-mongo-dsl.

Der Ausgangspunkt war ein Hilfsdienst, um ReactiveMongoTemplate einfacher zu verwenden, aber als die Funktionen zunahmen und ich begann, sie in mehreren Projekten wiederzuverwenden, kam ich zu dem Schluss, dass es nicht richtig ist, dass das Ausführungsmodell eines bestimmten Frameworks die Grenze der Bibliothek selbst bildet. Der Kern von 1.0.0 verwendet MongoExecutionContext als Ausführungsvertrag und nutzt direkt den MongoDB Reactive Streams Driver.

Diese Veränderung ist nicht dazu gedacht, Spring Data MongoDB auszuschließen. In Spring-Anwendungen können die Collection-Namensgebung von ReactiveMongoTemplate, MongoConverter, benutzerdefinierte Konvertierungen und reaktive Audits über den MongoExecutionContext-Adapter verbunden werden. Der Kern bleibt unabhängig vom Framework, und nur die benötigten Anwendungen verwenden die bestehenden Spring-Einstellungen.

Gleichzeitig wurde auch klarer, dass die MongoDB Driver-Funktionen, die bereits gut bereitgestellt werden, nicht innerhalb der DSL neu implementiert werden sollten. Allgemeine Aggregationen können direkt als Bson-Stufen empfangen werden, und für Search/Vector gibt es Escape-Hatches wie SearchOperator, VectorSearchQuery, driverOptions(...), stage(Bson). Dies ist eine Entscheidung, um sicherzustellen, dass neue Funktionen des Drivers sofort verwendet werden können, ohne auf die nächste Veröffentlichung der DSL zu warten.

Die Trennung zwischen allgemeinen Abfragen und Search/Vector erfolgt, um die tatsächlichen Pipeline-Beschränkungen von MongoDB nicht zu verbergen. $search und $vectorSearch haben Einschränkungen in der ersten Stage, und Funktionen, bei denen der Aufrufer die gesamte erste Stage steuern muss, können auf aggregation() zurückgreifen.