7 Gründe für JHipster

Ein neues Software-Projekt steht an, und die Meinungen gehen auseinander, auf welcher Basis man arbeiten soll. Dieser Beitrag liefert 7 Gründe, warum JHipster eine gute Grundlage für ein neues Angular/Spring-Boot Projekt sein kann. Zusätzlich zählen wir noch drei Argumente auf, die gegen die Verwendung dieses Applikations-Generators sprechen können.

1. Entwicklungsgeschwindigkeit

Mit keinem anderen Werkzeug hat man so schnell eine vollständige Webanwendung erstellt wie mit JHipster. Nach der Installation der notwendigen Pakete tippt man auf der Konsole einfach „jhipster“ ein, beantwortet 19 multiple choice Fragen (von denen die meisten Antworten auf dem Standardwert bleiben können), und schon entsteht eine vollwertige Webanwendung mit Spring-Boot-Backend und Angular-Frontend.
Die Geschwindigkeitsvorteile enden allerdings nicht beim Anlegen einer neuen Applikation. Auch das Generieren von Entities gestaltet sich durch „jhipster entity“ und das resultierende Frage-Antwort-Spiel erfreulich einfach.
Durch den übersichtlichen Aufbau des Codes wird auch das nach dem Generieren notwendige Implementieren einer Business-Logik leichter, da meist auf den ersten Blick klar ist, an welcher Stelle man eingreifen muss.

2. Best practice out-of-the-box

Eine frisch generierte Applikation bringt folgende Dinge mit:

• Benutzerverwaltung mit E-Mail-Verifikation und Passwort-Reset
• Übersetzungsmöglichkeit der Applikation in verschiedene Sprachen
• Liquibase für Datenbank-unabhängige Changelogs

Das ist nur eine kleine Auswahl der Features, die man sonst händisch konfigurieren muss.

3. Einfaches Deployment

Eine normale, monolithische JHipster Anwendung lässt sich auf viele Arten deployen. Wie bei Spring Boot üblich, sind nach einem Maven-Build zwei WAR-Files vorhanden. Eines ist geeignet, um sich klassisch auf einem Applikationsserver (Tomcat, Websphere, …) deployen zu lassen. Das andere hat den Server schon inkludiert, und lässt sich einfach mit “java -jar app.war” starten.
Zusätzlich gibt es die Möglichkeit, mit Docker zu deployen. “docker-compose -f src/main/docker/app.yml up -d”, und schon startet die Applikation inklusive Datenbank.
Dadurch, dass der Angular-Client auch im WAR-File steckt, ist es nicht notwendig, den Client extra zu deployen.

4. Fokussieren auf Business Funktionalität

Dadurch, dass JHipster so viele nichtfunktionale Anforderungen abdeckt, bleibt einem als EntwicklerIn mehr Zeit, um sich auf die Umsetzung der funktionalen Anforderungen zu konzentrieren. Das spart Zeit und bringt Velocity!

5. Code Qualität und Tests

Eine frisch generierte JHipster App kommt mit hoher Testabdeckung, sowohl auf der Server-, als auch auf der Client-Seite. Jedes Entity, das man sich generieren lässt, bringt auch gleich eine ganze Reihe von Standard-Tests mit. Somit fällt es leicht, auf die existierenden Tests aufzusetzen, um die selbst implementierte Business Logik zu testen.
Zusätzlich bringt JHipster Unterstützung für statische Source Code Analyse mit Sonarqube mit.

6. Sauberes Design durch Bootstrap

JHipster setzt auf Bootstrap, um ein einheitliches Design für die Benutzeroberfläche zu bieten. So kann man als EntwicklerIn viele verschiedene UI-Elemente verwenden und bauen, ohne eine einzige Zeile CSS Code schreiben zu müssen. Gerade für Business-Anwendungen kann es sein, dass dieses Standard-Aussehen gut genug ist.

7. Open Source Community

JHipster hat eine lebhafte Open Source Community, die das Projekt vorantreibt. Durch die Natur von Open Source ist es natürlich auch möglich, dass man selbst Änderungen einbringt, und diese dann in das Hauptprojekt wandern.

Nach diesen Gründen für die Verwendung von JHipster hier noch ein paar mögliche Gegenargumente.

1. Kein typisches Angular CLI Projekt

Die empfohlene Variante, ein neues Angular Projekt zu starten, ist die Verwendung des Command Line Interface von Angular. JHipster hat dieses Tool zwar auch eingebaut, aber die Projektstruktur sieht doch ganz anders aus als ein Projekt, das man sich von der Angular CLI generieren lässt.
Nachteile davon können sein, dass es bei auftretenden Problemen schwieriger sein kann, im Internet eine Lösung zu finden, da die meisten EntwicklerInnen mit Angular CLI Projekten arbeiten.
Die Angular CLI macht viele für den EntwicklerInnen unsichtbare Sachen im Hintergrund, vor allem was das Bauen der Applikation mit Webpack angeht. Diese Dinge sind bei JHipster sichtbarer, und vor allem sehr unterschiedlich. Der Grund dafür liegt in der engen Verzahnung von Backend und Frontend, die das Ausliefern in einem einzelnen WAR-File ermöglicht.

2. ng-jhipster kann Probleme machen

JHipster hat einige Teile des Client-Codes in ein NPM-Module namens “ng-jhipster” ausgelagert. Der wichtigste davon ist die Unterstützung für Übersetzungen.
Wenn man in einer generierten Applikation etwas machen will, dass Änderungen in diesem eingebundenen Modul erfordert, macht das alles etwas komplizierter. Mögliche Lösungsansätze:

• Code händisch zurück in die Applikation integrieren
• Forken des Moduls
• Einen Beitrag zum JHipster Open Source Projekt leisten, damit sich das Modul für alle ändert.

3. Upgraden ist kompliziert

Wenn JHipster eine neue Version veröffentlicht, ist das toll für alle EntwicklerInnen, die damit eine neue Applikation generieren wollen. Was macht man allerdings, wenn man ein Projekt hat, das mit einer älteren Version generiert worden ist, aber von Bugfixes und Features der neuen Version profitieren will?
JHipster hat hier einen Upgrade-Mechanismus, der allerdings immer schlechter funktioniert, umso mehr man von der generierten Applikation abweicht.
Der beste Ansatz, den wir für dieses Problem gefunden haben, ist der parallele Betrieb eines Git-Repositories, in dem die generierte Applikation ohne weitere Code-Änderungen liegt. Dieses Repository kann man bei jeder neuen Version problemlos upgraden. Dann kann man die Änderungen begutachten und bei Bedarf in die echte Applikation übernehmen.

Wir hoffen dieser Artikel hilft bei der Entscheidung, ob JHipster für dein Projekt geeignet ist oder nicht.