Back when I worked for a small consulting company, I had the privilege of working on a special internal project. This was back in the days of Struts 1 and JSP and this project was a self-generating web application generator. So when I heard about JHipster (albeit belatedly since they’re on version 5), I had to check it out.
The latest version of JHipster gives users the option to generate a Java or Kotlin back end and front ends in either Angular, React or Vue.
I have a feeling I’ll be doing more with JHipster. So for this post, I’m going to take you through getting a simple application up and running in development mode while I give my impressions along the way.
JHipster requires Java, Node/NPM and Git to be installed.
To install JHipster, we’ll use npm to install it globally.
npm install -g generator-jhipster
We run the generator in the directory where we want our application. So first we’ll create a directory named TodoTracker and then cd into it.
Run JHipster from a command line.
Then follow the prompts. This example application is a monolith, uses JWT Authentication, SQL databases (H2 in Memory for dev and MySQL for production), EHCache, Gradle and Angular. I picked a few languages for internationalization and no extra testing frameworks or special features.
Running as Generated
We can import the project into Eclipse as an existing Gradle project. Then we can run it with gradlew bootRun. When the application starts up, it tells us our URLs in the console.
---------------------------------------------------------- Application 'TodoTracker' is running! Access URLs: Local: http://localhost:8080/ External: http://xxx.xxx.xxx.xxx:8080/ Profile(s): [dev, swagger] ----------------------------------------------------------
Now we can take a look at what we generated.
When we got to http://localhost:8080 we see the JHipster welcome screen.
If we log in as an administrator, we can explore a lot of cool features under the Administration menu. We can add additional users to the application, view application metrics such as JVM Metrics and more, check on the health of the application, view the configuration, review audit records such as log in activity, view and change logging levels for various packages in the application, use Swagger on the API, and actually connect to and query the database.
All of that stuff is really cool and sure makes developing and debugging easier, but we want to generate an application that does stuff we want to do. So we need to add our own entities to the application.
We can do that in JHipster by creating and importing a JHipster Domain-Language file. JHipster provides an online application called JDL Studio that lets us write our JDL file with real-time visualization.
In JDL Studio, we define our entities and other details about the application. In our case, we define our TodoItem entity, a couple of enums and then set up pagination, dtos, and services. There are quite a number of things we can configure with JDL. As we write the JDL, the diagram on the right automatically updates, so we can visualize our entity structure.
Once we have our entities the way we want them, we download the file into our application directory and import it.
jhipster import-jdl jhipster-jdl.jh
To change our entity structure, we can just modify our JDL, download a new file and run the command again. An open question here is what happens if you’ve already customized your code.
Now that we have some entities, let’s take a look at our project structure. The full application resides under the application root directory. The source code for Java and the front-end (Angular in our case) is all found under the src/main directory. When imported into eclipse, the Java under src/main/java is separated out into packages and the Angular is left under the src/main/webapp folder.
The other directories will seem familiar to anyone who’s worked with these various tools before. JHipster includes a .jhipster directory. In this example, it contains a json file for our entity.
The package structure is pretty standard (to the extent that there is a standard) for a Spring Boot REST API. It’s no trouble to find our entity, repository, and controller.
The same goes for the Angular side. I have less experience there but everything under the src/main/webapp folder is logically organized.
Running with Entities
In order to work with our newly added entity, we need to run both the back end with ./gradlew bootRun and launch our front end with npm start.
The application will open at http://localhost:9000 and will look similar to the application running on port 8080. The difference is that once we log in, we’ll see our TodoItem under the entities menu.
From the entity menu, we can now work with TodoItems. We have full CRUD functionality. Additionally, we can page and sort our items. There’s no search functionality provided. Perhaps specifying Elasticsearch when we were generating would have provided that.
We’ve just seen an overview of what JHipster can generate out of the box. We didn’t customize or edit a single line of code and we can operate on our entities. Overall, I’m really excited about this. I want to rewrite all the things with all the technologies.
Readers should expect to see more about JHipster. It’s hard to know where to go next with this, but definitely some sort of customization. (I’d rather not have Hipster on my application start pages). Exploring the other options is another possibility.
So expect more about JHipster here. And if I’m missing out on other application generators, leave me a comment.
One thought on “A First Look at JHipster”
Thanks for the kind reference to iStart
On Mon, May 27, 2019 at 7:00 AM Amy’s Programming Corner wrote:
> Amy DeGregorio posted: “Back when I worked for a small consulting company, > I had the privilege of working on a special internal project. This was > back in the days of Struts 1 and JSP and this project was a self-generating > web application generator. So when I heard about JHipst” >
LikeLiked by 1 person