Hello team,
Some news about JHipster Lite, and more details on what has been done since september.
If you're not interested, you can stop reading here :-)
Pascal
TL;DR
History:
- I started the project at the beginning of september, after holidays
- I started it because I didn't manage to contribute easily to generator-jhipster
- I started it because of NubesGen, as I saw the code and in my opinion, it's far better, far easier to understand than what we have in generator-jhipster
- I'll be honest: I lost my motivation because of the complexity, all these options to maintain, all these options to test...
- an example: I wanted to improve the unit test of the Security part for OAuth2, but I needed to do it too for JWT, for Reactive, etc... so I gave up :-D
- I tried to propose the modulith approach but I failed
- it tooks me several nights to do it and I'm not happy with the final result (see the different comments in PRs)
Description:
- similar to generator-jhipster, JHipster Lite can be used to quick start your Spring Boot + Java projects
- the difference is: the generation needs to be done, step by step, like you would do when you do real code in company for your customer
- Java 17 is mandatory
- opinionated Hexagonal Architecture structure
- 100% coverage in the generated project
About the generator:
- the generator is coded in Java, and it generates Java code
- JHipster Bom is at 69% :-/
- JHipster Online 50% :-(
- JHipster Control Center 35% :-((
- Mustache for templates
- Hexagonal Architecture too: each feature is in its own package, it means when you improve OAuth2 part, you don't need to worry about JWT, as it's completely separated
Negative point at the moment:
- you need to use swagger to generate your project, no front part yet
- few documentation, I'm focusing on adding features
Which features/options today?
Done:
- Init project
- Maven with Java 17
- Java base classes
- JaCoCo config for minimum coverage
- Sonar support
- Spring Boot
- Spring Boot MVC: Tomcat or Undertow
- Spring Security JWT, with Basic Auth
- Database: PostgreSQL or MySQL
- Liquibase
- Spring Boot actuator
- Spring Devtools
- Logging with AOP
- Logstash support
- Async configuration
- Spring Cache with Ehcache
- Springdoc
- Jib
- Spring Cloud Consul
- Spring Cloud Config
In WIP:
- use a web page instead of swagger, the front part will be with Vue3 + Hexagonal Architecture
- generate a front (will start with Vue 3)
- OAuth2
- Flyway
- User and Authority entities
Important part, which is not done yet:
- Gradle support
- Front part: Angular, React, maybe Svelte
Some stats:
- more than 60 stars, it's pretty cool :)
- 11 contributors, 2 womens
- already 7 releases, nearly 1 release per week
About Release:
- it took me 10sec to launch 1 single command and 3 minutes to write the Tweet, so, it's a total of 3min for a new release
- you can compare to generator-jhipster which took at least 4h or 5h, as it needs jhipster-bom, jhipster-registry, jhipster-control-center, react-jhipster, waiting Docker Hub, resync with generator-jhipster,
jhipster.github.io, jhipster-online, all sample apps, jhipster-devbox, documentation-archive, etc...
About tests:
- JHipster Lite with mvn verify -> 1m45 with 100% coverage
- generator-test with npm test -> 14m33 outch...
How I tried to solve different problems:
Problem #1: too many generated files
- it solved as with this approach, the developer will generate only what he/she needs
Problem #2: hard to customize
- same answer, it solved as with the step by step approach, the user can choose what he/she needs and so can easily edit the generated code, which is really small
- for example: generate Spring Security JWT -> then edit this part. It's like 10 java classes
- another example: you can choose to not generate Security part and code it yourself
Problem #3: too many options
- strangely, with JHipster Lite, we don't care about having too much options (thanks to this architecture)
- each options is in its own context, its own package, and do not depend on other options
- the contributors can easily add new options, and if it doesn't work anymore or not well maintained, the API can be disabled or the package can be deleted and that's all, the option is gone
Problem #4: complex template
- with this architecture + mustache, no complex templates
- separated options / separated templates
- you can compare:
- I don't care about having 2 SecurityConfiguration templates: 1 for JWT, 1 for OAuth2, as there are some common and specific parts
- this is done like this because the contributor who wants to improve OAuth2, doesn't need to care about the JWT
Problem #5: too many projects
- no external lib, mono repo, everything is in generated code
- see the release part, 3min to release JHipster Lite, at least 4h to release generator-jhipster
Problem #6: yeoman
- JHipster Lite is coded with pure Java (see the domain part, in Hexagonal Architecture)
- it does not depend on external frameworks, so it will be easy to migrate from Spring Boot to Quarkus, from Mustache to something else, if needed
- with this architecture, our "business / generator" codes do not depends on technology
What's next?
- I already did some small presentation to developers I worked with (some of them hate JHipster) and the opinion is the same: better approach, fit better to their needs
- I'm still convinced by this approach
- we could add later a CLI (using picocli), deploy this app like jhipster-online, use it as a Lambda function, build a native image etc
- if you need a demo or a presentation, I can schedule it with you
Have a nice day.
PS: sorry for my english, probably a lot of mistakes