Generating your project using JHipster quick start steps
- Install Java, Git and Node.js
- Install JHipster
npm install -g generator-jhipster - Create a new directory and go into it
mkdir myApp && cd myApp - Run JHipster and follow instructions on screen
jhipster - Model your entities with JDL Studio and download the resulting
jhipster-jdl.jdlfile - Generate your entities with
jhipster jdl jhipster-jdl.jdl
You are going to have a bootstrap project with a lot of features and functionalities already configured and implemented. I will share with you the JHipster features I like the most.
My 15+ Reasons to use JHipster
- Update all libraries and framework automatically when upgrading the JHipster version of the project (I upgraded from version 7.1.0 to 7.2.0 smoothly) - https://www.jhipster.tech/upgrading-an-application/
- Already configured Husky (configure git hooks for automatic tasks) - https://typicode.github.io/husky
- Already configured eslint (javascript code analysis and automatic fix) - https://eslint.org/
- Already configured EditorConfig to maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs - https://editorconfig.org/
- Already configured BrowserSync the time-saving synchronized browser testing - https://browsersync.io/
- Already configured Progressive Web App (PWA) to make your web app application installable on Android when opened inside google chrome - https://blog.ippon.tech/build-a-pwa-in-jhipster/
- Already configured spring profiles for development and production - https://www.jhipster.tech/profiles/
- When run on dev already generate external IP to access throw your phone or another device on your domestic network
- Already configured liquibase. Learn more on How to Use Liquibase to Update the Schema of Your JHipster Application by @avdev4j
- Already implemented user management module (registration, login, forgot password, roles)
- Every generated code has an automatic test implemented (Angular and Spring Boot), so after using the JHipster generator just run
./mvnw verifyand you are ready to go if all tests pass - Already built-in internationalization support!! - https://www.jhipster.tech/development/#internationalization
- The Angular and Spring Boot code is really easy to read and customize! In addition, there are many “helper” classes to assist you with business logic implementation!
- Already configured Cypress for end-to-end tests. Learn how to use cypress with Anthony Viard
- Already implemented a sophisticated error handler - https://www.jhipster.tech/managing-server-errors/
- Created a useful Readme.md file with instructions to explore and run your generated project.
I hope you have the time to try out JHipster. If you have any questions or just want to say something, please, use the comment section 😊
Top comments (10)
Nice series!
We used JHipster for a project in the getting started phase and eventually abandoned it. We kept the code though, we just stopped running JHipster to update the files.
There were several problems we couldn't get around and it ended up slowing us down beyond the initial setup.
I tried using it for projects such as node etc. and there it literally crashed for the simplest use case. Couldn't upgrade it either or really use it at all. Submitted an issue like a good OSS hacker and it got closed on a technicality: github.com/jhipster/generator-jhip...
Hi @codenameone 👋
Thank you for reading and I am glad that you are enjoying this jhipster series 💗
Thank you for sharing your experiences with JHipster, It's gold 🪙 to me. Let's talk about your valuable feedback 🤓
That's an interesting way to use it only as a bootstrap project for a fast start. But I agree that is not ideal.
I think that UUID is now available, but I didn't use it yet. I agree that's there are limitations on entity design, even though I like JDL so much.
If there isn't a way to map, you can customize and create the change with Liquibase, but it won't reflect on the UI and you will be like semi-automatic mode 😅.
I don't know if when you used it the Entity/DTO map was made using the awesome mapstruct.org. The mapping is basic but with mapstruct you can improve it easily.
Yes, it's created only a crud UI 👍
In my case as a backend Java developer, the AngularJS UI was everything I need to kick start my solo project. Then I created a dashboard screen with the main business logic. I improved my Angular knowledge while I am implementing the web app.
That's so true! It makes teamwork harder!
I can imagine that on a bigger project. Did you use the automatic update?
They are building a JHipster Lite version that uses the Hexagonal architecture which isolate the business logic, maybe that makes the upgrade smoothly. You could read more about it: Project scope/purpose and difference with JHipster
I felt the same before I understand why. It's on this series road map to talk about why JHipster doesn't use Lombok. I won't spoiled it now 🤭
I didn't try any blueprint before. Where this issue should be created? Should be create on the node blueprint project? Could you help me here @avdev4j ?
Glad to hear it's a welcomed comment. A couple of clarifications.
This project was created almost 3 years ago so UUID wasn't an option. I saw it was added but way after we did it. I'm not sure if it matches the strategy we ended up choosing.
With entities we have an inheritance hierarchy that's rather elaborate. It also maps to the DTOs which are different from the entities. Personally I think the inheritance in the entities was a mistake. We ended up with too many joins as a result. But that was the decision made by the team (against my intuition).
The plus side of the hierarchy is that we were able to leverage OOP very effectively and implement features with an elaborate visitor pattern. Pretty cool.
We hated Liquibase. During development it was redundant and painful. For most cases it made more sense to just wipe the database entirely. When we closed in on production we added flyway which is enough for what we need and MUCH simpler.
I don't recall the process for updating since it's been a couple of years. Not sure what we used. But a way to detect our changes and merge smoothly would have been nice. I hadn't heard of JHipster Lite, it sounds interesting. Thanks!
I read up why they don't use Lombok back then. I even tried adding it myself with their suggested options... It worked for some cases and failed in others. Not sure why. We still don't use Lombok today. I guess we'll just move to 17 at some point.
FYI I don't need that issue fixed anymore since I just went in a different direction for that.
More 🪙🪙🪙 experience shared!
You are a true Hipster! You used it 3 years ago, I discovered and build a web app last year 🙇
I agree about liquibase creating some overhead if the project isn't in production yet. May I do the same as you if my team supports the decision 👍. You aren't the first talking about how good flyaway is 🧐
Thank you for sharing your experience! You gave me a lot of insights about the jhipster tradeoffs .
Why use a tool which lies starting from the front page?
And then you see first option "Spring Boot". High performance? Really?
Hi @siy 👋
Thank you for sharing your opinion 🤗
I agree that Spring Boot isn't the highEST performance technology, but for sure it's a high performance depending on your solution design and goal.
Things are getting better with Spring Native for JHipstee
Spring Native don't change performance (sometimes native image performance is even worse than JVM-based version). It improves startup time, that's it.
Claiming that Spring performance is "high" is like claiming that "3" is "many". Yes, in some circumstances "3" might be "many", but usually it's just "few". Same is with Spring, which is full of performance-killing solutions like abuse of run-time reflection.
@siy, I didn't know the native image could be worst than JVM 😯
If you think of a microservice architecture, a solution deployed on Kubernetes will scale horizontally faster with native image and that's something good to have.
I am the kind of person that a half water glass 🥃 is almost full 😅
Yes and no. Instead of applying "microservice architecture" patterns blindly, let's look why you need to scale it and scale quickly. And here appears the problem: you need to scale it because initial performance is very bad. And you need to scale it quickly because, besides bad performance, overload handled even worse - Spring (to be precise - Tomcat) nearly stops handling requests. In microservice setup this is especially bad, because whole setup is not fault tolerant (despite advertising). So, deploying new instances quickly is the only way to mitigate the issue at least partially.
Besides much better performance, modern asynchronous solutions (no, Spring Web Flow is not one of them) handling overload much better, gradually increasing response time and sustaining throughput. This means that new instances have enough time to start. And number of necessary instances is much lower - i.e. handling of the same load is cheaper and causes lower impact on the environment.
Which feature do you wish it comes already configured/implemented every time you start a new project❓ Could be any of those I have already listed or a new one.
Thank you for reading this post. Send me some ❤️ & 🦄 to support me and enhanced this post's visibility 🤩
If you find the content interesting, follow me 👣