Intro to JHipster

My first look at JHipster

So I’ve just recently switched jobs, and one of the most interesting aspects of my new employer, Ippon, is that they develop JHipster. One of my first tasks was to familiarise myself with the framework, what it is, how to use it, and how to deploy it, and boy was I in for an adventure. On first glance it looks like a standard Yeoman based scaffolder for Java applications. You answer some questions in the CLI, you hit enter, and boom, out comes a fully formed Spring-Boot Java application. However the more I looked into it, the more I started to enjoy all the included goodies.

Features

Microservices

Instead of just generating Java Applications, JHipster has an entire microservice approach for deploying applications. People talk about microservices as a nebulous cure to all technological woes, but the reality can be quite complex and difficult if not properly managed. JHipster presents a vision of how to build and deploy a microservices solution, based on Spring Cloud and Netflix OSS. It might not align to everybody’s vision, but it’s a solid, production-ready foundation. In its most basic configuration, there are three main components to the JHipster microservice stack:

Note: There is also the option for an authorisation server, but that’s a discussion for another time.

Entity Creation

JHipster has an inbuilt UML like language which allows you to model relationships between entities. I’ve struggled with these kinds of tools in the past (I’m looking at you Rational Software Architect), but this one is pretty intuitive. It generates helpful boiler code not just at the entity level, but also full CRUD level endpoints. It also generates sensible Java code which won’t make you vomit. There is an online tool called JDL Studio, which allows you to model your entities. You then then feed the generated file into the entity sub generator, and out comes all the entities beans, Liquibase scripts, endpoints and tests you could ever dream of.

Docker

Docker is used for spinning up dependencies, and can be used to package your application. Docker make everything better *exclusions apply.

Testing

Out of the box it contains options for a bunch of testing frameworks, on both the Java and JavaScript side of the fence. Tools like Protractor are available out of the box with PhantomJS. I’d probably swap that out for a Chrome based Docker image with a Remote Web Driver until headless Chrome is available.

CI Generation

Need to add a pipeline to Gitlab? Done.

Deployment

Out of the box it’s trivial to run a JHipster application through docker-compose. Everything is there with a nice little bow on it. If you want to run something in production, there are a bunch of deployment options in that space. Due to my pathological love of containers, I gave the Rancher option a go. Due to its need to have access to a Docker Registry, it’s not quite as straightforward as some of the other interactions, but it does work as it says on the box. I ended up using Amazon’s Container Registry, which worked after following this.

Where to use JHipster?

The obvious starting place is the microservice generator. It’s a quick and relatively painless way of generating Java microservices. I’ve worked for a number of organisations which have developed similar, but not nearly as feature rich tools internally, and it’s a great way of reducing all that Sprint 0 project setup malarchy. I mean who doesn’t like wiring up Spring Contexts?

Rancher UI with JHipster Deployed

The gateway component is an interesting concept, but certainly for the customers I’ve worked with, a harder sell. They’ve spent a number of years investing in monolithic API gateways, and there would certainly be a reluctance to move away from that towards a more feature-centric API and application approach. Saying that, the ridginessness of the monolithic API gateway and the constraints it can put on innovating front end applications may foster a willingness to push gateway functionality back into application teams. This would be where the JHipster Gateway would really shine, particularly for JVM centric organisations.