DEV Community

Discussion on: My 15+ Reasons to use JHipster

Collapse
 
renanfranca profile image
Renan Franca

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 🤓

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.

That's an interesting way to use it only as a bootstrap project for a fast start. But I agree that is not ideal.

It's pretty strict about entities so we couldn't do anything "creative" with the entities or DTOs (complex inheritance, UUID PK etc.). The entity/DTO mapping was also very simplistic (understandably)

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.

Mapping to the UI is too simplistic once we built our front end it was no longer as useful. Plus the react support wasn't as mature at the time

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.

Our front end developers don't want to touch our backend code. They have their own system and just build TS code. They copy the code into the repo later to merge it in. This is pretty common for frontend people. So the integration with the front end workflow isn't as useful for us

That's so true! It makes teamwork harder!

We had to change files and merging with the updates on every major change was a pain

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 feel it's a bit too verbose. A lot of its features can be better achieved using simpler tools. E.g. Lombok or Java Records solve a lot of the verbosity problems in entity/DTO creation

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 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..

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 ?

Collapse
 
codenameone profile image
Shai Almog

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.

Thread Thread
 
renanfranca profile image
Renan Franca

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 .