The previous two posts in my series on helpful tools for developing CRUD applications were about tools that addressed very specific problem areas: API format specifications and code generation from those specifications in particular.
This post will be both less about APIs and solving specific CRUD-related problems but about a tool that deals with CRUD app requirements in a comprehensive manner. This tool I’m talking about is called – not so slightly tongue-in-cheek – JHipster.
Both inspired by tried-and-true frameworks like Ruby on Rails yet at the same time not completely trying to re-invent the wheel but rather building upon existing robust technologies such as Spring Boot and Angular, JHipster provides an extensive application generation toolkit. In fact and very much in the spirit of toolkits like Spring Boot most of JHipster is about carefully selecting the best tools for a particular job rather than trying to create yet another framework for solving problems that have long since been solved.
JHipster takes an opinionated approach for assembling and configuring the various parts of its technology stack in order to ensure that everything “just works” ™ out of the box. This approach doesn’t give you a whole lot of discretion when choosing and composing your app’s components but it has the huge benefit of providing a mostly fixed template for a certain category of applications. After all, that’s what we want when rightfully complaining about how tedious and repetitive churning out CRUD applications is: A fixed set of rules and automatically generated entities that deal with that repetitive and tedious parts so developers can focus on those hard parts of an application’s behaviour that actually require a human to think them through and create a solution for.
In order to work its magic JHipster draws upon the code generation tool Yeoman. It also covers everything you could possibly want when writing a CRUD app such as testing / QA and database migrations (using Liquibase). In terms of front-ends it supports both AngularJS 1.x and Angular > 2, as well as Bootstrap 3 and 4. It also integrates with Elasticsearch so your CRUD entities are instantly searchable as well. In keeping with its hipster persuasion JHipster of course supports Microservice creation and production deployments via Docker, too.
JHipster allows you to both initially bootstrap your application and to generate further entities later on.
While I do think that an approach like the one taken by JHipster does have its merits – otherwise I wouldn’t have presented it here after all – such a solution to common business software development tasks unfortunately comes with its own set of problems, too. Take for instance this section of the JHipster documentation describing the process of creating a new model entity:
…For each entity, you will need:
A database table
A Liquibase change set
A JPA Entity
A Spring Data JPA Repository
A Spring MVC REST Controller, which has the basic CRUD operations
An Angular router, a component and a service
An HTML view
Integration tests, to validate everything works as expected
Performance tests, to see if everything works smoothly…
That’s a whole lot of code in various different languages (SQL, Java, XML, JavaScript) and distributed throughout several locations in your project. With an opinionated approach it makes sense to create all those different components because you want to take as many potential requirements into account as possible without having to worry about the developer having to make decisions about which of these components might be needed now or even later (which can lead you down a dangerous path known as analysis paralysis …). However, it also means that there will be much more code to maintain and worry about. Modifying a mostly generated CRUD app once domain model changes occur can become particularly arduous and a real headache. Worst case, you end up having more work with modifying and maintaining your application than had you written it from scratch yourself.
Moreover, as soon as an application’s UI has to accommodate less generic, more specific use cases or if you want to provide a more focused, less one-size-fits-all UX a mostly automatically generated UI will fall apart rather quickly.
So, tools like JHipster in my opinion have to be taken with a grain of salt: They can be tremendously helpful with getting bootstrapping and maintaining mostly uniform CRUD applications. They can become a burden in their own right as well though. So, knowing when to use such a tool and when to take a more lightweight approach like a simple Spring Boot application is key.
Software generation can be conducive to solving a particular class of business problems but it’s certainly not the be-all and end-all it was hailed as in 1990s.