JSON für Spring Boot Endpunkte erzeugen

[Oneixee5]

Was meint ihr, ist es nachteilig JSON für REST-Endunkte direkt in der Datenbank zu erzeugen, anstatt den ganzen Weg über Entities, DTO's und Jackson zu gehen?
Bspw. direkt über natives SQL:

select
  JSON_ARRAYAGG (
    JSON_OBJECT(
      'id' is b.ID,
      'label' is b.LABEL
      -- mehr Spalten
      absent on null
    ) order by b.LABEL returning clob
  ) JSON
from TABLE b
  inner join ...
  inner join ...
where b...

Ein Wechsel der DB ist für die betroffenen Projekte sowieso unrealistisch und das sind wahre Monster (Exadata). Die größte Rolle spielt hier Geschwindigkeit und Latenz.
Das Ergebnis der Abfrage wäre dann immer eine String - fertiges JSON.

 

[Robert Zenz]

Ich sehe da keinen Nachteil. Die Frage ist: Schreibt ihr in Java Logik welche diese Objekte verwendet oder habt ihr das alles in der Datenbank? Wenn ihr das alles in der Datenbank habt (dann erstmal meine Gratulation dazu die Geschaeftslogik dort zu haben, das fand' ich immer die besten Projekte, super einfach neue Schnittstellen/Oberflaechen zu machen) dann bringt es nichts wenn ihr alles doppelt abbildet.

Weil genau das ist es ja wenn man ein POJO-Model passend zur Datenbank hat, man hat alles doppelt. Da gibt es dann die Ansaetze das man das Model aus der Datenbank generiert (meine Meinung: "Wenn du Code generierst hast du etwas falsch gemacht"), oder du generierst die Datenbank aus den POJOs (was teilweise echt leidlich funktioniert und Migrationen sind Horror). Wenn du dir das alles also ersparen kannst, dann waere das doch etwas gutes. Mal abgesehen davon dass Spring ja doch einiges an Komplexitaet und Eigenheiten mitbringt (Monolithen brauchen keine Dependency-Injection, unter anderem...das aendert sich eh nie dynamisch) und wenn du da eventuell auf etwas leichtgewichtigeres setzen kannst (Spark?) dann ist das ja nur ein Vorteil.

 

[Oneixee5]

Die Frage ist: Schreibt ihr in Java Logik welche diese Objekte verwendet oder habt ihr das alles in der Datenbank?

Beim Laden des JSON möchte ich soweit keine Logik im Java/Endpunkt/Service haben. Security und Validierung der Parameter wenn erforderlich ja ansonsten nur die Abfrage->JSON und ab zum Client. Für Security und Validierung habe ich Annotions gebaut. In der SQL-Abfrage ist dann vermutlich noch etwas Logik enthalten, so etwas wie - als gelöscht markierte Datensätze ausschließen. Das würde ich aber sowieso machen und nicht erst im Service umsetzen.
Das Speichern der Daten ist dann etwas Anderes. Da muss teilweise. viel mehr validiert werden. Das passiert aber nicht in der DB, sondern in Services mit Entities und auch Hibernate Validator.

 

[mrBrown]

https://blog.jooq.org/stop-mapping-stuff-in-your-middleware-use-sqls-xml-or-json-operators-instead/ 🙂


Würde nur auf hohe Testabdeckung achten und u.U. auf Views setzen

 

[walk]

Imho ist das eine Architekturfrage. In einer Mikroservice-Architektur gehe ich mit dem Ansatz mit, dass man hier die Logik nicht im Service kapselt und zusätzlich POJOs / DTO/VOs usw. etabliert. Da soll der Service als Schnittstelle zur Datenbank dienen, um die Business-Logic kümmern sich dann andere Services.

Bei einem monolithschen Ansatz sieht die Sache dann anders aus. Dass DTOs Klassenexplosionen ermöglichen ist sicherlich eine Gefahr, aber das trifft ja nicht nur für Container-Klassen zu, sondern auch für Projekte in denen man es mehr als gut gemeint hat, alles möglichst generisch zu halten und dann möglichst viele abstrakte Klassen bereitzustellen.

Den Artikel von @mrBrown sehe daher skeptisch. Als seien DTOs, Lombok, und überhaupt Mapper Teufelszeug und gar nicht notwendig.

 

[mrBrown]

Inwiefern macht es da einen Unterschied, ob Monolith oder Microservice?

In beiden Fällen hab ich Daten und Geschäftslogik im gleichen Projekt (in einem Fall halt „mehrere Geschäftslogiken“), und in beiden hab ich den Fall, dass ich Daten nur stumpf ohne weitere Verarbeitung nach außen geben muss - und genau in solchen Fällen kann man sich das Mappen von Datenbank-Result -> Entitäten -> DTOs -> JSON einfach sparen und direkt JSON nutzten, da fällt nichts weg außer Transformationen zwischen verschiedenen Darstellungsarten.

 

[walk]

@mrBrown: Kommt doch eher auf darauf an, welche Daten ich zurückgeben möchte, oder nicht? Ich möchte doch eingrenzen können, welcher Aufrufer welchen Attribute einer Entität sehen darf. Das regel ich mit dem Ansatz ohne DTO dann über dedizierte SQL-Abfragen? Bin mir halt nicht sicher, ob ich hier wirklich Komplexität einspare.

 

[mrBrown]

@mrBrown: Kommt doch eher auf darauf an, welche Daten ich zurückgeben möchte, oder nicht? Ich möchte doch eingrenzen können, welcher Aufrufer welchen Attribute einer Entität sehen darf. Das regel ich mit dem Ansatz ohne DTO dann über dedizierte SQL-Abfragen? Bin mir halt nicht sicher, ob ich hier wirklich Komplexität einspare.

Wie ich sagte, sinnvoll ist das nur, wenn ich …

[…]Daten nur stumpf ohne weitere Verarbeitung nach außen geben[…]

… muss.


Wenn man die Daten erst weiter verarbeiten muss, macht es durchaus auch Sinn, das irgendwo zwischen Datenbank und Browser zu machen.

 

[Robert Zenz]

Den Artikel von @mrBrown sehe daher skeptisch. Als seien DTOs, Lombok, und überhaupt Mapper Teufelszeug und gar nicht notwendig.

Ja aber genau das ist es doch! Die Antwort ist weniger Magie, nicht noch eine Schicht damit es einfacher wird. Aber gut, angesichts dessen dass ich an genau so einem Framework mitgearbeitet habe (und immer noch fest an den Ansatz glaube) bin ich da vielleicht auch ein wenig voreingenommen.

Inwiefern macht es da einen Unterschied, ob Monolith oder Microservice?

In den meisten Projekten scheint der Unterschied nur die Anzahl der Container zu sein. Wenn man einen Monolithen in Kleinstdienste zerlegt, hat man immer noch einen Monolithen...aber dafuer mit vielen beweglichen Teilen.