How JHipster and Docker saved my first Angular Java project

Do you face these challenges in your Java project?

• Are you or your team struggling with Angular, React, NoSQL, or microservices?
• Uncertainty about how DevOps, containers, and the cloud impact Java?
• Can’t find the results-oriented online training for these new technologies?

If your answer is “Yes”, then I can help you!

Wait, who made me the expert!? I faced all these challenges completing my first Angular project last year. But thanks to JHipster and Docker, I successfully led the project into production and saved a ton of time. I liked JHipster and Docker so much that I started a second project with it in my spare time already.

So let me tell you my story. If you like what you hear, then let me teach you JHipster and Docker so that you can save a ton of time on your next Java project, too!

My first Angular project

It was a Thursday afternoon in June 2018. The customer on my green-field Java web project had just signed off on the first version of the data model. Great! However, now I had just 3.5 days to deliver the application, with log-in & user roles, administration features,ten entities from the data model and data import from CSV files…

To make matters worse, I was also the only developer back then — on my first Angular project! My reputation was on the line, too: A new client had hired me to work for their most important customer. Failure was not an option.

Then on Tuesday morning (a day before the deadline), the customer walked in and asked: “So, what do you have to show?” My pulse raced, and I asked myself: “Oh boy, what do I do now?”

The World is Changing

We Java developers had it easy for a long time: we work on the large enterprise applications that power the world. That guaranteed a steady stream of well-paid and exciting work. Sure, Microsoft’s .NET stack can be fierce competition, but most enterprises prefer the choice in our Java ecosystem.

But now there is trouble in paradise:

• Technological changes Most applications will be moving into the cloud (or “hybrid clouds” on-premise), changing the way we build applications. Monolithic applications are giving way to micro-service architectures. Containers will continue to revolutionize software delivery. NoSQL databases are powerful upstart challengers to the relational workhorses we have used for decades. Competitive ecosystems have emerged: Facebook runs on PHP, Twitter on Ruby on Rails, Google on pretty much any language out there. JavaScript is today’s “Write once, run anywhere” language for the front end — and increasingly the back end. And the rise of mobile devices demands new solutions that relegate Java to “just a REST API.”
• Cultural changes Agile projects deliver business value quickly. So you can no longer spend weeks or months anymore on just setting up your development environment and getting servers ready. The DevOps movement means we developers now run the applications we write — including the dreaded emergency calls on Sunday at 4 am. 😓
• Economic changes Companies always like to cut costs, especially in uncertain economic times such as today. This means we need to do more with less when building our applications. The enterprise is also increasingly adopting open-source to lower costs. As a result, we’re facing different middleware stacks — goodbye Oracle and Websphere, hello MySQL and Tomcat! Apart from learning the middleware, we now sometimes have to build administration and scalability features that we used to take for granted.

Now don’t despair, there’s still a place for us Java developers in this brave new world! However, we must embrace change, learn new technologies and deliver better applications faster.

This is a huge relief! 😃

But wait, how exactly do we deliver better applications faster and learn new technologies?

JHipster to the Rescue

Back to my first Angular project and that Tuesday morning in June 2018: What could my application do? Everything that the customer had asked for and then some: more administration features, responsive layout for mobile devices, unit tests in Angular and Java, and automated browser tests. Moreover, the application and the database ran in Docker on my Mac and the Linux test server, ready to be deployed to production.

How did I pull that off?

One word: JHipster. JHipster is an open-source code generator (more on that later). Using it is like adding a superstar developer to your team who writes all the “plumbing code” and picks the best libraries.

So here is what happened last June:

• Before Thursday afternoon I had already built the application skeleton with JHipster. That how I managed to have an application with log-in and user roles, system management functionality, a menu bar, and a responsive layout for mobile devices. I simply adopted the built-in user roles and tweaked the UI a bit. Finally, I used JHipster native support for Docker to deploy the application and the database. Using Docker is like having your own set of “Linux servers in a JAR file” for your application, along with the database and whatever else you need.
• Midday Thursday afternoon to Monday noon I created the ten entities in JHipster by defining the data model using the “JHipster Domain Language” (JDL). JHipster then generated the back end and front end code for the “CRUD” screens (create, read, update and delete), unit tests for Java & Angular, and automated browser tests. I did need a couple of attempts to get the relationships between the entities right. Finally, I fine-tuned the generated Angular screens. Yes, I did work over the weekend. And yes, today it would probably take me only one day to accomplish the same result. 😌
• From Monday noon to Tuesday morning I wrote the code for importing four entities from uploaded CSV files. That took about eight hours — yep, more overtime.

So that is how JHipster and Docker saved my day!

What JHipster Can Do for you

JHipster will help you to build a Java web application (monolith or microservices) or learn how to build one. Sure, you can do this without JHipster, but that will take longer, and you’ll get worse results!

Let me deliver some proof. Say your new project is building a new Angular application with a Spring Boot back end. Well, how hard can that be?

Building an Application On Your Own: Angular

You get this screen if you generate a new Angular application with the Angular CLI:

You only have a single view, no internationalization, no menus. The application is not responsive and to be honest, it’s kind of ugly.

Now, the JavaScript ecosystem is vast and develops quickly. That is good because you have plenty of choices for how to add missing features. But it’s bad because you have plenty of choices: Which choice is the right one? Will it still be the right choice six months down the line? Let me give you two examples here:

• When you start an Angular application, you have five styling choices: “Plain old CSS,” SCSS or Sass (which are two different syntax options from the library that’s confusingly also called Sass), Less and Stylus. So, which one is it? 😣
• JavaScript has a dizzying array of frameworks for unit tests and automated browser tests. When you ask, “How do I test in Java?”, then “jUnit and Selenium” is usually the right answer. But in JavaScript, you have Karma with Jasmine, Jest and QUnit for unit tests and Puppeteer, PhantomJS, Mocha with Chai, and TestCafe for browser tests. These are just the main options right now… And change is inevitable: Within a three month period last year, JHipster switched from Karma to Jest for unit tests first — and then from PhantomJS with Jasmine to Mocha with Chai for browser tests. Sheesh!

Building an Application On Your Own: Java

Let’s show the “JavaScript kids” what a good on-boarding experience is! I used the Spring Initializer to create a Spring Boot application with Spring MVC, Spring Security, JPA with Hibernate, Liquibase (for database maintenance) and H2 (an embedded database).

So here is what the application looks like:

I would really like to show you a screenshot, but I can’t: The application didn’t run because the Liquibase configuration was missing! Spring security was not configured, either — no user roles, no default credentials. Spring profiles (such as “dev” and “prod”), HTML pages, CSS files, and directories for images and JavaScript files — all of these are missing, too.

So let me get this straight: We’re using the Spring Framework, the “comprehensive programming and configuration model for modern Java-based enterprise applications” (source), through Spring Boot, which “is designed to get you up and running as quickly as possible, with minimal upfront configuration of Spring” (source). And we’re getting this application, which is neither comprehensive, nor configured, nor actually running?!

Building an Application On Your Own: Putting things together

So Angular had an OK start, Spring Boot a horrible one. We can overcome this. However, we’re still left with two separate applications, two separate code repositories and two different build systems:

• How do you fold the Angular application into the Java project?
• How do you build, configure, and deploy an Angular application with Maven or Gradle?
• How do you implement aspects shared between Angular and Java, such as log-in and user roles?

Learning how to Build an Application On Your Own

Now that we covered building an Angular application with a Java back end, let’s look at learning how to build one. You search for Angular online courses in the usual places, like Udemy or LinkedIn Learning. Here is what you find:

• You learn things you don’t care about Angular courses typically use Node.js as the back end and Visual Studio Code as the IDE. Thank you very much, but we are happy with Java and Eclipse or IntelliJ.
• You don’t learn things you do care about Most courses take short-cuts with toy implementations, such as hard-coded log-ins and no internationalization. They specifically do not tell you how to create production-ready code. You know, the hard stuff that you really need later: configuration, logging, different build environments, maintainability, error handling, useful tests, system management, and so on.
• You constantly hear things you already know Most courses target beginners and explain in detail things we Java developers already know, such as inheritance, annotations, or dependency injection.
• These problems multiply Need to learn about more than just Angular? Well, pick additional courses for CSS, HTML, JavaScript, Typescript (the “JavaScript with types” language that Angular uses), Spring Boot, Spring MVC or Spring Security — mostly unrelated, but all with the same problems! If somebody explains to me one more time the difference between a class and an object or between content and mark-up, I think I am going to lose it. 😤

So what is JHipster really?

Earlier, I said JHipster is like adding a superstar developer to your team. Now let’s dive in.

JHipster is an open-source code generator and creates complete monolith or microservice applications. Unlike other code generators, JHipster doesn’t add large custom runtime environments (such as GSP or GORM with Grails). You’re mostly working with “pure” Java and Angular or React, which is great when you’re learning or searching for answers on Stack Overflow. I said “mostly,” because JHipster does have an Angular utility library for internationalization, a simple “publish & subscribe” event manager and a few more bells and whistles. The generated code is clean, follows best practices and looks like a superstar developer wrote it!

JHipster sets up a production-ready project with a unified build system, user management, system information, and automated testing in ten minutes. It supports continuous integration, deployment to Docker and Cloud, and regularly updates all libraries.

The back end of a JHipster application uses Spring Boot 2.1 with Java 8 or 11, and either relational or NoSQL databases. The front end is either in Angular or React. Support for the Java alternative Kotlin and the front end library Vue.js uses plug-ins (JHipster calls them blueprints) and is in beta status.

And what is Docker?

Docker is free virtualization software that revolutionizes software distribution: Docker turns all the servers we need for our application into “one set of code” that runs on our PCs, the test server and the production environment. So no more time wasted on setting up test and production servers, or struggling to recreate production issues because of different hardware or software!

How does Docker accomplish that?

• Docker puts the operating system, one application, and its dependencies into an efficient package that runs everywhere: the Docker Image. You build some of these packages (like your Java application) yourself from Dockerfiles (text files that define your image), but you pull most of them (such as databases or caching servers) from a Docker Registry. The public Docker Registry, Docker Hub, hosts all of the applications you’ll ever need in your next Java project — for free. To put it in familiar terms, a Docker Image is like a JAR file, a Registry is like a Maven repository, and Docker Hub is like Maven Central.
• You assemble Docker Images into a system (e.g., your application and a database), either through a simple Docker Compose file or the more powerful Kubernetes system. Docker Compose / Kubernetes is like a build file that creates a WAR, EAR or Fat JAR file for your application.
• Finally, the Docker Engine runs Docker Images in Docker containers. You can run multiple containers with the same image simultaneously. That means the Docker Engine is like the JRE.

Compared to alternative approaches for runtime hardware dependencies, Docker builds, distributes and runs your applications much more easily and efficiently. Since you can get all the software you need for your project for free from Docker Hub, you should really look into Docker for your next project!

How JHipster and Docker save you a ton of time

JHipster and Docker save you a ton of time and make your life a lot easier. How exactly? Let’s look at the challenges for us Java developers, which I outlined at the very beginning.

Are you or your team struggling with Angular, React, NoSQL, or microservices?

• Learning on the job JHipster gives you a massive head-start in your project by generating a complete application. And then JHipster saves you even more time: You just update your data model in the JDL file — JHipster then gladly (re-)generated all the front end and back end entity code for you. All this keeps your customer busy with reviewing your work, which buys you time to learn in parallel.
• Tests Testing is like flossing your teeth: We all know it’s good for us, but most of us don’t do it often enough. Also, how exactly do you test JavaScript code or write browser tests these days? JHipster picks the best test libraries for you — and swaps them out if something better comes along. JHipster also generates tests for the built-in functionalities (such as login and administration) and the entities generated from your data model. So you get running tests and see how to write them yourself.
• Security fixes You can spend endless hours scouting all the frameworks and libraries for security fixes, both in Java and JavaScript. And as a reward, when you pull in a new library version, you may break your application! With JHipster, the JHipster team does the hard work for you: They find the security fixes and figure out which library versions work together. You simply upgrade JHipster and let it upgrade your project libraries. This patches security holes without breaking your application, automatically.
• Technologies decisions Angular vs. React, relational DB vs. NoSQL, or monolith vs. microservices — how do you pick new technologies? You don’t know them (hence “new technologies”), so you rely on somebody else’s judgment. With JHipster, you can study and compare running code instead! You generate real applications from your own data model, with production-ready code that adheres to best practices.

Don’t know how DevOps, containers, and the cloud impact Java?

• DevOps DevOps needs automated build, test, and deployment. We know how to do that in Java. But what about JavaScript? Luckily, JHipster’s got you covered with Angular and React: It integrates them into the Java build, sets up unit tests and automated browser tests for them, and deploys them as part of the WAR file.
• Containers Containers are a great way to deliver applications. But how do we build them for our Java applications? JHipster and Docker work wonderfully together: JHipster gives you the Dockerfile for the Java application, a Docker Compose file for running your application and the database as one system, and Docker Compose files for other software you need (such as an OpenID / OAuth server).
• Cloud It seems that these, everybody wants to run their applications in the cloud. JHipster can help you there, too: It has built-in support for deploying to Kubernetes, AWS, Google App Engine, Cloud Foundry, Heroku, and OpenShift (beta status).

Or can’t find proper online training for these new technologies?

The online training out there today takes short-cuts with toy implementations, doesn’t use our Java ecosystem and teaches you things you already know. Learning with JHipster is a whole different ballpark: You start with a Java application that uses the technology you need — whether it is Angular, React, NoSQL, or microservices. The code is production-ready and clean and follows best practices. You then study the code, change it, and observe the results. Granted, you will still need additional training — but a lot less so. And you don’t waste any time because you stay in the Java world.

You don’t have to use all of JHipster

My project last year took full advantage of JHipster. However, your project doesn’t have to:

• Your database schema You can use your own database schema. JHipster uses Liquibase for the database schema and JPA entities for the database interactions — so you can add your Liquibase file. Alternatively, you can disable Liquibase altogether and provide the database schema another way (e.g., with SQL scripts). You can change the table name, column names, and relationship settings right in the JPA entities code.
• Your user management You may need to plug in existing user management (e.g., your corporate directory) or cloud-based authentication. The JHipster JDL allows you to switch off the built-in user management. Spring Security is the best way to integrate other authentication methods integrated.
• No front end generation You may want to build your own UI on top off the JHipster back end. Or maybe you heavily customized the initial UI that JHipster initially created and now want JHipster to leave that alone. Simply exclude some or all of the entities from front end generation in the JHipster JDL.
• No entity generation JPA may not fit your data model because your data model looks completely different. For instance, if you use event sourcing, or querying the database with JPA is too slow or not flexible enough. In that case, you just generate the initial application with JHipster and write the entitiy code yourself.

The most pared-down usage is to provide your own user management and to not generate entities at all with JHipster. Is it still worth using JHipster in that case? That’s a definite “yes” — JHipster still gives you all of these benefits:

• Unified build system
• Automated testing
• System information screens
• Support for continuous integration
• Deployment to Docker and Cloud
• Regular library upgrades

When JHipster isn’t right for you: building an application

JHipster may not be right for you if you want to build Java applications. Here is why:

• Front end platform not in JHipster JHipster currently only creates Angular or React applications (Vue support is a work in progress). If you need a different front end platform, you can’t use JHipster.
• Java 8 or 11 not allowed JHipster uses Spring Boot 2.1 which requires Java 8 or Java 11. If you must support an older version of Java, then JHipster isn’t for you.
• Spring Boot or Spring not allowed JHipster uses Spring Boot 2.1 and Spring 5.1. If your organization prohibits the use of those platforms, then JHipster isn’t for you.
• Incompatibilities with application servers JHipster generates a WAR file for deployment into “traditional” application servers. Especially older application servers may not be compatible with the versions of Spring, Spring Boot, Hibernate or other libraries in the WAR file. In that case, you can’t use JHipster, either.
• Open Source Licensing Your organization may have a review process for licenses of open-source libraries. This post does not constitute legal advice, so please check with your organization for open-source license requirements. Typically, the Apache license and the MIT license are considered business-friendly. For a monolith application at least, the two possible license issues are Hibernate (LGPL 2.1) and Logback (LGPL 2.1 & Eclipse Public License). If your organization doesn’t permit these licenses, you may replace these libraries with Apache projects: OpenJPA and Log4j 2. I am not sure if replacing in particular Hibernate would work. If you need to replace these two libraries but it doesn’t work, or you don’t want to go through the effort, then JHipster isn’t for you.

When JHipster isn’t right for you: learning

JHipster may not be right for you if you want to learn how to build Java applications. Here is why:

• Technology not in JHipster Say you want to learn Scala or Java EE. You can’t learn them with JHipster: Scala isn’t a back end option, and Java EE probably never will be because JHipster deeply integrates with Spring Boot.
• Your learning style Learning with JHipster means “learning by doing”: You look at the code generated by JHipster, change it, and observe the results. You will still need additional training, but a lot less so. If you aren’t comfortable with this kind of learning, then JHipster isn’t for you.

Wrap-up

This wraps up my introduction to JHipster and Docker. I laid out several challenges that Java developers face and saw how JHipster helped me to overcome these challenges last year — and showed you how you could master them, too. I also described how to customize the feature set of JHipster and defined situations where JHipster is probably not right for you.

Next on the “Better Java Projects Faster with JHipster and Docker” tutorial

If you want to learn more about JHipster and how it can boost your productivity, then please check out the next installment of my tutorial “Better Java Projects Faster with JHipster and Docker.” There, we’ll start a JHipster project together. Future installments will dive down into various aspects of JHipster, such as testing, continuous integration, deployment to Docker and the cloud, customization, changes to the data model, and a whole lot more.

I am excited about teaching you JHipster and Docker. I hope you are excited about learning it, too!