Sollte man Spring Boot in privaten Projekten benutzen?

• Erstellt am: 01. April 2025

Man neigt ja dazu Techniken und Tools die man beruflich nutzt, auch irgendwann im Privatleben anzuwenden. Oft ist das ja auch keine ganz schlechte Idee. Erkenntnisse aus dem agilen Projektmanagement lassen sich beispielsweise super auf Bauvorhaben in unserem Haus anwenden. Altes Haus = legacy Code und so. Aber wie verhält sich das bei Softwareprojekten? Ist man gut beraten die Frameworks aus dem Enterprise Umfeld auch für private Projekte zu nutzen?

Im Job

Mit dem Spring Framework und Spring Boot habe ich jeden Tag im Job zu tun. Fast alle unserer Services verwenden das Spring Framework. Für unseren Fall macht Spring auch sehr viel Sinn und wir können super von den vielen Möglichkeiten und Freiheiten profitieren. Alles lässt sich sehr feingranular einstellen und auf unsere Bedürfnisse anpassen. Aber genau in diesen Freiheiten und Möglichkeiten liegt auch die Herausforderung. In unserem Produkt wurden viele dieser Freiheiten schon von Kolleg:innen vorgedacht. Das macht es in der Umsetzung sehr einfach, da die Bewegungsräume aus denen man eigene Entscheidungen treffen kann schon dankenswerterweise eingeschänkt sind. Nichts desto trotz müssen alle Architekturentscheidungen gut bedacht und abgewägt werden, legt man hier doch den Grundstein für einen im besten Fall langlebigen Service.

Und Privat

Privat hingegen setze ich Projekte eher schnell auf, um ein konkretes Problem in diesem Augenblick zu lösen. Genau so schnell wie die Projekte aufgesetzt werden, sind sie doch meist auch wieder verschwunden. Zum einen weil ich für das Problem in der Zwischenzeit eine andere Lösung gefunden habe, zum anderen weil sich die Welt zwangsläufig einfach weitergedreht hat und das Problem jetzt nicht mehr existiert. Sprich: Nicht der Weg, sondern das Ziel ist oftmals das Ziel!

Neue Ideen sollen einfach mal schnell umgesetzt werden. Teilweise auch um die Machbarkeit zu prüfen. Die notwendige Konfigurationsarbeit und das Abhängigkeitsmanagement für Spring Projekte ist da eher hinderlich als hilfreich. In meinem privaten Projekten kommt es mir auch nicht immer auf hundert-prozentige Richtigkeit an, sondern die Lösung muss dann eher einfach funktionieren.

Vor einigen Tagen wollte ich mich wieder an eine Idee wagen. Dafür habe ich aber nach dem Job und anschließender Care-Arbeit nur noch spät abends Zeit. Also habe ich mir am ersten Abend den Laptop geschnappt und meine IDE geöffnet. Dank der Spring Boot Integration und Spring Initializr lassen sich neue Projekte ja schnell zusammen klicken. Aber welche Pakete braucht man denn jetzt eigentlich? Kurze Recherche in vergangenen Projekten und im Internet brachte etwas Erleuchtung. Schnell war eine erste Liste der grundlegenden Abhängigkeiten angelegt: Dev Tools, Lombok, Spring Configuration Processor und Spring Web gehören auf jeden Fall bei mir immer dazu. Dann fing aber das Überlegen an:

• Brauche ich Datenbank Support?
• Wenn ja, welche Datenbank will ich einsetzen?
• Will ich dieses Mal HATEOAS verwenden?
• Welches Datenbank-Migrations Tool will ich verwenden? Flyway, Liquibase oder doch JOOQ?

Ganz zu schweigen von dem großen Fass Spring Security. Keine Frage, die Library ist sehr mächtig und es ergibt auf jeden Fall Sinn sie einzusetzen. Meiner Erfahrung nach macht es die Entwicklung am Anfang aber unnötig schwer. Wenn Spring Security nicht konfiguriert ist, wird erstmal jeder Request konsequent abgelehnt. Ich wundere mich dann immer erstmal warum ist das jetzt so ist, bis es mir dann dämmert: Du bist mal wieder mit Spring Security als Abhängigkeit gestartet.

Im Job setze ich in unseren neueren Services gerne auf OpenAPI um die Schnittstelle zu anderen Systemen oder aber auch dem Frontend zu definieren und gleichzeitig zu dokumentieren. Daraus lassen sich auch prima Interfaces für Contoller und Responses generieren. Der Ansatz nennt sich API First und hat den unschlagbaren Vorteil, dass es keine undokumentierte APIs geben kann und dass Backend und Frontend immer die selbe Version der API verwenden. In Spring Initializr gibt es aber leider keine fertige Integration, also muss diese erst nachträglich hinzugefügt und konfiguriert werden. Will man jetzt noch dass die Interfaces automatisch beim Bauen der Anwendung erzeugt und aktualisiert werden, sind weitere Eingriffe in die Gradle oder Maven-Dateien notwendig.

Das ist alles kein Hexenwerk und ist eigentlich ganz gut bei den jeweiligen Bibliotheken dokumentiert. Aber bis die Doku gefunden und gelesen ist und das darin Enthaltende dann auch so umgesetzt ist, dass es schlussendlich funktioniert, geht einiges an Zeit drauf. Ich habe bei oben genannten Projekt zwei Abende nur damit verbracht das Projet aufzusetzen und zu konfigurieren. Vorallem lag das, denke ich, an der fehlenden Routine beim Aufsetzen neuer Projekte. Man könnte jetzt sagen: Na dann starte doch öfter auf der grünen Wiese und übe das Aufsetzen von Spring Boot. Aber damit ist mir ja auch nicht geholfen. Damit wird ja die eigentliche Herausforderung die ich habe nicht gelöst. Ich will mich in meiner Freizeit ja auch nicht damit rumschlagen neue Projekte aufzusetzen. Trotzdem kann das mal vorkommen, wenn ich neue Techniken ausprobiere.

Was ist aber jetzt die Lösung?

Wie genau die aussieht kann ich abschließend auch noch nicht sagen. Möglicherweise bleibt Spring Boot ein guter Teil davon. Die Erfahrung aus dem Job bringt natürlich einige Vorteile mit.

Mir sind aber vorallem drei Dinge für das schnelle Aufsetzen von Projekten wichtig.

Ich brauche einen einfachen Blueprint, keine großen Auswahlmöglichkeiten. Der Techstack ist eigentlich immer gesetzt und unterscheidet sich nur minimal je nach Anforderung. Die wichtigste Konfiguration sollte beim Start schon vorhanden sein, sodass ich mich direkt auf die Problemlösung konzentrieren kann. Im besten Fall tippe ich ein Kommando in das Terminal und erhalte ein Verzeichnis mit einem läuffähigen Projekt, das ich mit einem weiterne Kommando direkt starten kann.

Aus der Webentwicklung bin ich etwas verwöhnt was die Zeiten angeht, bis eine Änderung im Browser sichbar ist. Java und Spring bieten zwar mit den Dev Tools den Hot Reload von vereinzelten Klassen an, bei den Java-basierten Backends habe ich aber die Erfahrung gemacht, dass nicht immer alle Änderungen per Hot Reload ausgetauscht werden können. Interpretierte Sprachen wie Javascript haben da einen unfairen Vorteil. Warum den Vorteil aber nicht ausnutzen und das Backend auch in Javascript bzw. Typescript schreiben?

Zu guter Letzt muss sich mein Service leicht in ein Docker-Image packen lassen. Das Image darf auch gerne von kleinerer Größe sein, damit es sich leichter shippen lässt. Heutzutage ist Speicherplatz zwar meißt kein Thema mehr, aber Internetverbindungen hier auf dem Land sind teilweise immernoch eher schlecht konfiguriert.

Es spricht also einiges für ein Typescript Backend mit pnpm oder yarn als Paketmanager. Dann könnte man auch gleich ein Projekt-Blueprint auf Github hosten und mit dem yarn create Kommando einfach neue Projekte erstellen. Und es wäre mal wieder ein guter Vorwand, ich meine Notwendigkeit, sich mit neuen Dingen, wie den Yarn Starter Kits, zu beschäftigen. Davon lebt der Blog hier ja.

Ich geh dann mal das Create Vite React Template auschecken.

Happy Coding!