dark

Getting Hip with JHipster

Avatar

JHipster ist ein Framework, um Spring-Boot-basierte Web-Anwendungen und Microservices mit Angular, React oder Vue-Frontends zu generieren, zu entwickeln und zu betreiben. Mit JHipster lässt sich eine Anwendung bootstrappen und das Datenmodell erzeugen, sodass man sich auf das Implementieren der Businesslogik konzentrieren kann.

JHipster kombiniert unterschiedliche Technologien und Frameworks, konfiguriert diese nach aktuellen Best-Practices und stellt sicher, dass die verwendeten Technologien reibungslos miteinander funktionieren. Wer keine Zeit hat, sich für einen Prototypen beispielsweise in die Besonderheiten von Spring-Security einzulesen oder in die Konfiguration von Angular und Webpack einzuarbeiten, sollte sich JHipster einmal genauer ansehen. JHipster hilft nicht nur Anfängern, sondern auch erfahrenen Entwicklern schneller produktiv zu sein[17].

 

JHipster in Zahlen

JHipster wurde im Jahr 2013 gestartet, seitdem gab es sechs Major-Releases. Die aktuelle Version ist 6.1.0 vom Juni 2019. Das Projekt ist sehr aktiv [19] und wird von einigen Firmen finanziell gesponsert. Im letzten Monat wurden fast 100 Pull-Requests gemerged und mehr als 70 Issues geschlossen. Das Kernteam besteht aus 31 Mitgliedern, darunter auch zwei Java-Champions und insgesamt 500 Contributors. Einige Teile, wie zum Beispiel der Kubernetes-Support, werden direkt von Google entwickelt. Unter den Nutzern von JHipster[2] befinden sich neben Google, HBO und Pivotal auch Firmen wie Siemens und Bosch.

GitHub-Pulse Mai/Juni 2019. (Abb. 1)

 

JHipster hat fast 14.000 Stars auf Github und nach eigener Angabe mehr als 25.000 Downloads pro Woche. Durch die aktive Community und die Aktivität des Teams, können Fehler schnell behoben und Probleme gelöst werden.

 

JHipster-Online

JHipster bietet verschiedene Installationsarten an[3]. Die Dokumentation empfiehlt die lokale Installation. Mit JHipster-Online [7], das selbst mit JHipster entwickelt wird, kann man eine JHipster-Anwendung konfigurieren und als ZIP-Archiv herunterladen. Wenn man seinen GitHub- oder GitLab-Account mit JHipster-Online verbindet, dann können die Projekte direkt in einem Git-Repository generiert werden. Weiterhin kann man verschiedene Entitätsmodelle verwalten und editieren und diese direkt in eine generierte Anwendung importieren. JHipster-Online erzeugt dabei einen Pull-Request auf dem Projekt, sodass man als Entwickler alle Änderungen noch reviewen kann und evtl. eingerichtete CI-Pipelines die Änderungen bauen und testen können. Demnach ist es sehr einfach verschiedene Anwendungskonfigurationen und Datenmodelle zu testen. Allerdings sollte man JHipster ebenfalls lokal installieren, da einige Funktionen wie beispielsweise Deployments bisher noch nicht von JHipster-Online unterstützt werden. Zudem ist es empfehlenswert, Docker und Docker-Compose zu installieren. Damit lassen sich die erzeugten Compose-Skripte für Datenbanken verwenden, sodass man diese nicht auf dem lokalen System installieren muss.

Anwendungskonfiguration in JHipster-Online. (Abb. 2)

 

Module und Blueprints

Da JHipster im Kern eine Spring-Boot-Anwendung ist, können alle Konfigurationen durch modifizierte Versionen überschrieben oder erweitert werden. Außerdem versucht JHipster die einzelnen Technologien in der Standardkonfiguration zu verwenden und Modifikationen nur vorzunehmen, wenn diese unbedingt notwendig sind [13]. Dadurch sind Anpassungen einfach möglich. Im Zweifel genügt ein Blick in die Dokumentation des entsprechenden (Upstream) Projektes.

 

Falls man größere Anpassungen vornehmen möchte, kann man auch ein Modul [10] oder einen Blueprint [11] entwickeln und JHipser-Online on-premise installieren, sodass automatisch immer das eigene spezielle Modul zusätzlich bei der Generierung einer Anwendung verwendet wird. Ein Modul hat Zugriff auf die Konfiguration der JHipster-Anwendung und kann, wie zum Beispiel ein Sub-Generator, Dateien anlegen. Über bestimmte Erweiterungspunkte, sog. needles, kann ein Modul bestehende Dateien erweitern oder modifizieren. Es können beispielsweise neue Menüpunkte oder weitere Maven-/Gradle-Dependencies eingefügt werden. Im Unterschied zu einem Modul kann ein Blueprint existierende Dateien überschreiben oder löschen und eine eigene Menge von Dateien ausliefern. Damit ist es dem Autor eines Blueprints möglich, u.a. Spring-Boot durch ein anderes Framework zu ersetzen, die Konfiguration an die Bedürfnisse des eigenen Unternehmens anzupassen oder Java durch Kotlin zu ersetzen[14]. Module sind seit JHipster 3 verfügbar, Blueprints erst seit Version 5 (als Beta). Daher ist die Auswahl an Blueprints noch nicht sehr groß. Seit Version 6 ist der offizielle Blueprint um Vue.js als Client-Side-Framework verwenden zu können in Version 1.0.0 verfügbar [15].

 

Let‘s get started

Gemäß Installationsanleitung[4] muss ein JDK (11), NodeJS in der aktuellen LTS-Version, Docker und Docker-Compose installiert werden. JHipster selbst kann via NPM installiert werden.

 

(Listing 1)

Mit Version 6 wurden weitere Installationsarten [24], wie Homebrew oder die JHipster-Devbox [23], eine Vagrant-basierte virtualisierte Entwicklungsumgebung abgekündigt, da der Nutzen entweder gering oder der Wartungsaufwand zu hoch gewesen ist. Nach der Installation eines Blueprints, z.B. vue.js [15], via npm install -g generator-jhipster-vuejs kann dieser beim Erstellen einer Anwendung verwendet werden. Eingabe von jhipster –blueprint vuejs startet der Generator im Terminal. Die anschließenden Fragen können mit dem Vorgabewert beantwortet werden (Abb. 3). Neben MySQL kann auch PostgreSQL verwendet werden. Auch zwischen Maven und Gradle kann man wählen. Für den Anfang sind die Standardvorgaben zu empfehlen. Damit werden Unit- und (Spring-) Integrationstests für den Serverteil generiert. Für den Frontendteil werden im Standard Unit-Tests mit Jest erzeugt, sodass jede JHipster-Anwendung eine sehr gute Bewertung bei der Analyse mit Sonar bekommt [25]. Bei Bedarf können sowohl E2E-Tests via Protractor, Performancetests mit Gatling und Behaviour-Driven-Tests mit Cucumber generiert werden [26].

Konfiguration der JHipster-Anwendung. (Abb. 3)

 

Nach der Generierung der App lässt sich die Anwendung mit ./gradlew starten. Nachdem der Java- und der Frontend-Build erfolgreich durchgelaufen sind, lasst sich die Anwendung mit localhost:8080 öffnen und man wird von der JHipster-Willkommensseite begrüßt. Das Java-Backend lässt sich mit ./gradlew in einem Terminal starten und in einem weiteren Terminal das Frontend mit npm run start. Nach dem Einfügen eines div Tags in die Datei src/main/webapp/app/core/home/home.vue sind die Änderungen nach kurzer Zeit im Browser zu sehen.

Durch die Integration der Spring-Boot-Dev-Tools muss auch bei Änderungen am Java-Code nicht die komplette Anwendung neu gestartet werden. Momentan läuft die Anwendung noch im sogenannten Development-Profil. Daher sind die JavaScript- und CSS-Dateien noch nicht optimiert und als Datenbank wird H2 verwendet. Im Production-Profil kann die Anwendung gestartet werden. JHipster erzeugt für alle externen Services (z.B. Datenbanken) passende Docker-Compose-Skripte, damit man als Entwickler die Datenbank nicht lokal installieren muss.

 

(Listing 2 – Starten der Anwendung im Production-Profil)

Nach dem Anmelden mit dem hinterlegten Standard-Login admin, admin hat man neben einer Benutzerverwaltung, einer Übersicht der erzeugten Metriken (Antwortzeit, Cache-Statistiken, JVM-Metriken) auch die Möglichkeit, die Log-Level zur Laufzeit zu ändern. Die Sprachumschaltung zwischen seinen gewählten Sprachen klappt reibungslos. Auf diese Weise hat man mit wenigen Befehlen eine Web-Anwendung mit Benutzerverwaltung, Security, REST-API und einem modernen Frontend generiert. Nun kann man mit dem Erstellen und Testen des Datenmodells fortfahren.

JHipster Willkommensseite. (Abb. 4)

 

Das Datenmodel

Im ersten Schritt soll ein spezieller Workflow abgebildet werden, bei dem alle Teams relativ autonom arbeiten können. Zwischen einzelnen Aufgaben gibt es gewisse Abhängigkeiten. Zum Beispiel kann das Team Einkaufswagen erst dann neue Produktinformationen verarbeiten, wenn das Team Produkt diese Daten auch bereitstellt. Diese Abhängigkeiten sollen explizit dargestellt werden und z.B. soll ein Ticket für das Einkaufswagenteam erstellt werden, wenn das Produktteam sein Ticket abgeschlossen hat. Dazu wird ein einfaches Modell verwendet. Jedes Team hat einen Workspace, der mehrere Listen mit Aufgaben beinhaltet. Diese Listen sind entweder intern oder dienen als Outbox bzw. Inbox eines anderen Teams. Die Aufgaben sollen später aus dem Ticketsystem in das neue Tool synchronisiert werden. Am Ende folgt eine einfache Ansicht der Aufgaben für die Teams, ohne dass diese mit Informationen konfrontiert werden, die üblicherweise nur für das Projektmanagement relevant sind.

Datenmodell. (Abb. 5)

 

(Listing 3 – Erzeugen der Entität Team)

Für jede Entität alle Fragen erneut zu beantworten ist überhaupt nicht “hip”. Die CLS ist auch nicht die einzige Möglichkeit, Entitäten anzulegen.

Konfiguration einer Entität mit dem Entity-Generator. (Abb. 6)

 

JDL

Mit dem JDL-Studio[6] lässt sich das Entitätenmodell mit einer domänenspezifischen Sprache beschreiben. Das Model wird dann direkt im Browser als Klassendiagramm gerendert. Neben Entitäten kann man auch ganze Anwendungen und sogar Microservices mit JDL definieren und somit fast vollständig ohne CLI arbeiten.

 

(Listing 4)

Das fertige JDL-Model lässt sich dann exportieren und mit jhipster import-jdl jhipster-jdl.jh in die eigene Anwendung importieren. Neben Liquibase-Changesets, um die Datenbanktabellen anzulegen, werden alle nötigen Spring-Data-Repositories und Entitätsklassen mit entsprechenden JPA-/Hibernate-Annotationen erzeugt. Für jede Entität steht eine einfache CRUD-Oberfläche (Abb. 8) (Abb. 9) zur Verfügung, die über eine REST-API mit dem Backend kommuniziert. Der aktuelle Stand kann dann ins Versionskontrollsystem gepusht werden.

(Listing 5 – Entitätsdefinition via JDL)

JDL Model als Diagram. (Abb. 7)

Generierte CRUD-Oberfläche (Übersichtstabelle) mit automatisch erzeugten Demodaten. (Abb. 8)

Generierte CRUD-Oberfläche (Detailansicht). (Abb. 9)

 

Betrieb und CI/CD

Wer sich mit dem Betrieb von Servern und Datenbanken nicht beschäftigen möchte, kann Plattformen wie Heroku oder Cloud-Foundry verwenden, welche die Konfiguration von Zertifikaten, Datenbanken und Web-Servern erledigen. JHipster unterstützt neben Heroku und Cloud-Foundry auch AWS, Kubernetes und Azure [9].

Mit jhipster heroku wird der Heroku-Sub-Generator gestartet. Es muss ein Name für die Anwendung vergeben und ausgewählt werden in welcher Region (US oder EU) die Anwendung laufen soll. Um nicht immer die Anwendung auf dem lokalen Rechner bauen und die .jar Datei hochladen zu müssen, kann man die Anwendung von Heroku bauen lassen (Abb. 10). Der Sub-Generator erstellt eine Anwendung auf Heroku, erweitert die Build-Files (pom.xml oder build.gradle) um die nötigen Plugins, erstellt automatisch die passende Datenbank auf Heroku, konfiguriert die Datenbankverbindung der Anwendung und deployet den aktuellen Stand. Nach ein paar Minuten ist die Anwendungen unter https://javaprosample.herokuapp.com/ erreichbar.

 

Erzeugen einer Heroku-Konfiguration. (Abb. 10)

Natürlich kann man auch seinen Prototypen automatisiert bauen, testen und im besten Fall auch direkt in der Cloud deployen lassen. Wer GitLab nutzt, kann den JHipster-CI/CD-Sub-Generator [8] verwenden, um automatisch eine passende Konfiguration für sein Projekt zu erzeugen. Neben GitLab werden auch Jenkins-Pipelines, Travis und Azure-Pipelines unterstützt. Nach dem Starten des CI-/CD-Generators mit jhipster ci-cd müssen noch einige Details ausgewählt werden. Eine Möglichkeit ist, seine Anwendung mit Sonar zu analysieren und von GitLab Aktualisierungen direkt auf Heroku bereitzustellen zu lassen. Insgesamt erzeugt JHipster eine Pipeline, die aus mehreren Schritten besteht. Der Deploy-Schritt ist dabei im Standard optional. Nach dem Committen und Pushen der Konfiguration startet GitLab direkt die Pipeline mit der erzeugten Konfiguration. Seit Version 6 werden Unit- und Integrationstests in verschiedenen Stufen der Pipeline ausgeführt und statt JUnit 4 wird bereits JUnit 5 Jupiter zur Ausführung aller Tests verwendet.

Erfolgreicher Ablauf der erzeugten GitLab-CI-Pipeline. (Abb. 11)

 

Fazit und Ausblick:

Mit JHipster lässt sich eine moderne Web-Anwendung innerhalb eines Tages erzeugen und in der Cloud betreiben. Der Entwickler kann sich auf sein eigentliches Ziel konzentrieren. Auch alle Schnittstellen und Datenbankentitäten lassen sich von JHipster erzeugen. Dank der JDL lässt sich sowohl die Konfiguration der Anwendung (z.B. OAuth2 statt JWT) als auch das Datenmodell leicht anpassen.

Nachdem JHipster 6 den Sprung auf Spring-Boot 2.1 und Java 11 vollzogen hat, konzentriert sich das Team auf den Feinschliff vorhandener Funktionen. Neben der Weiterentwicklung der JDL, so dass alle Optionen via JDL definiert werden können, ist geplant, Aktualisierungen von bestehenden Anwendungen zu vereinfachen, insbesondere, wenn viel eigener Code geschrieben wurde. Dadurch soll JHipster noch mehr zu einem Framework werden, das nicht nur das Scaffolding einer Anwendung vereinfacht wird, sondern den kompletten Lebenszyklus und Entwicklungsprozess abdeckt.

Durch die Blueprint Funktionalität, die seit Version 6 den Betastatus verlassen hat, wurde das Interesse von weiteren Communities geweckt. Das JHipster Core-Team portiert die Scaffolding-Funktionen momentan auf C#.Net. Maintainer von Micronaut und Quarkus versuchen ebenfalls einen JHipster-Blueprint für beide Frameworks zu bauen.

 

Frederik Hahne arbeitet als Software Entwickler bei der WPS Management GmbH in Paderborn an der offenen B2B Integrationsplattform wescale (wescale.com). Er ist Organisator der Java User Group Paderborn (jug-pb.gitlab.io) und hat in Paderborn die lokale Devoxx4Kids Gruppe ins Leben gerufen. Seit 2015 ist er Mitglied des Java Hipster Core Teams und betreut momentan hauptsächlich den Gradle Build und den Vue.js Blueprint des Projekts. Er twittert unter @atomfrede und bloggt gelegentlich unter https://atomfrede.gitlab.io/.

Firma: wescale.com

https://www.xing.com/profile/Frederik_Hahne/cv

https://www.linkedin.com/in/frederikhahne/

https://github.com/atomfrede

Links/Quellen/Verweise:

 

  1. https://jhipster.tech
  2. https://www.jhipster.tech/companies-using-jhipster
  3. https://www.jhipster.tech/installation
  4. https://www.jhipster.tech/creating-an-entity
  5. https://start.jhipster.tech/jdl-studio
  6. https://start.jhipster.tech
  7. https://www.jhipster.tech/setting-up-ci
  8. https://www.jhipster.tech/production
  9. https://www.jhipster.tech/modules/creating-a-module
  10. https://www.jhipster.tech/modules/creating-a-blueprint
  11. https://www.jhipster.tech/heroku
  12. https://www.jhipster.tech/policies
  13. https://github.com/jhipster/jhipster-kotlin
  14. https://github.com/jhipster/jhipster-vuejs
  15. http://www.jhipster-book.com
  16. https://www.packtpub.com/application-development/full-stack-development-jhipster
  17. https://www.openhub.net/p/generator-jhipster
  18. https://gitlab.com/atomfrede/javapro-jhipster-sample
  19. https://sonarcloud.io/dashboard?id=javaprosample
  20. https://javaprosample.herokuapp.com
  21. https://github.com/jhipster/jhipster-devbox
  22. https://www.jhipster.tech/2019/05/02/jhipster-release-6.0.0.html
  23. https://sonarcloud.io/dashboard?id=io.github.jhipster.sample%3Ajhipster-sample-application
  24. https://www.jhipster.tech/running-tests
Total
0
Shares
Previous Post

Technische Schulden in der DevScoreOps-Welt

Next Post

Netzwerksegmentierung funktioniert auch in der Cloud

Related Posts