Ende 2006/Anfang 2007 stellte sich meinem Partner in Crime Myke und mir die Frage, auf welchem Technologie-Stapel Doodle basieren soll. Bei der Programmiersprache fiel die Wahl trotz des damaligen Hypes um Ruby (on Rails) auf Java, womit sich die Anschlussfrage stellte, welche Web-Bibliotheken und/oder -Gerüste aus dem Java-Ökosystem zum Einsatz kommen sollen. Wie ich schon in der Mai-2008-Ausgabe vom Bulletin SEV/VSE geschrieben habe, entschied ich mich damals bewusst gegen Spring:
„Wer sich in letzter Zeit mit Webapplikationen im Web-Umfeld auseinandergesetzt hat, wird sich womöglich fragen, was denn mit Spring sei. Spring ist ein von Spring-Source gefördertes Open-Source-Projekt. Publikationen im Java-Umfeld scheinen sich heutzutage fast immer auch mit Spring zu befassen, nicht selten auch mit entsprechender Erwähnung im Titel. Anstatt zu begründen, weshalb Spring eingesetzt werden soll, muss man heute als Projektverantwortlicher wohl eher begründen, weshalb Spring nicht eingesetzt werden soll: Wir waren und sind schlicht und einfach der Meinung, dass der Preis für die Einbindung und Wartung von Spring für den für Doodle zu erwartenden kleinen Mehrwert gegenüber einer JSF- und Hibernate-Lösung ohne Spring zu gross wäre.“
Tatsächlich konnte ich Spring weitere zwölf Jahre aus dem Weg gehen, nicht zuletzt weil ich Projekte, auf die ich mehr (railOscope, Elohna) oder weniger (Nezasa, TestingTime) Einfluss hatte, in Richtung Play gestubst hatte.
Ab Ende 2018/Anfang 2019 musste ich mich für eine Kundin doch noch mit Spring (Boot) auseinandersetzen. Dank der fünften Auflage von Spring in Action war der Einstieg keine Sache. (Übrigens setze ich mich zur Zeit für die gleiche Kundin wieder mit Spring auseinander und lese deshalb zur Repetition die sechste Auflage von Spring in Action.)
Nun da ich sowohl Spring (Boot) als auch Play sehr gut kenne, kann ich gut verstehen, dass Spring im Allgemeinen und Spring Boot im Speziellen sich so hoher Beliebtheit erfreut. Projekte, die darauf setzen, hätten wirklich keinen triftigen Grund zu migrieren. Mir fällt die Wahl für zukünftige Projekte nichtsdestotrotz immernoch leicht: Play bleibt meine erste Wahl!
Dazu kommt, dass ich Geschäftslogik dank Play/sbt einfach in einem Unterprojekt konzentrieren kann (was auch mit Spring/Maven resp. Spring/Gradle gut machbar ist, wie ich bei oben erwähnter Kundin schon gezeigt habe), um so eine clean/hexagonal/onion Architektur zu erzwingen. (Das lesenswerte Get Your Hands Dirty on Clean Architecture zeigt Alternative Projektstruturen dafür auf – am Beispiel von Spring Boot … :-/) So nebenbei reduziert das auch die Abhängigkeit vom Web-Gerüst auf ein Minimum.
Squeng AG 