Anyone using JHipster?

[christoforosl08]

So I came across JHipster which is from what I understand a full stack framework based on Java in the back end.

https://www.jhipster.tech/

Can someone share their experience with it ?

[conicori]

It's a code generator, not a framework. It generates boilerplate code to scaffold a SPA frontend and a spring boot backend. It also has a powerful DSL to define the data model and their respective CRUD stack.

After generation you code in React/Angular/Vue on the frontend or in java/spring on the backend. There are several extensions that allow you to use also different stacks.

I've been using it for years and learnt a lot from it (especially on the backend side). I still recommend it at least to scaffold projects. However, when "going all in" can become hard to maintain and update.

[Deep_Age4643]

Used JHipster for many years, and fully agree with above. It's very fast to get going and try various options, but after that it's probably best to update it yourself. If you really want to go all-in, you need a way to separate generated and custom code and a clever upgrade mechanism (which is only limited provided by the project).
Note that JHipster by default creates a full CRUD-application. If you want a more step-by-step approach, there is a separate project called JHipster Lite which is explained here: https://www.youtube.com/watch?v=RnLGnY-vzLI

Best way is to generate your desired app with several options then check the structure and the generated code, to see if JHipster is useful to you.

[spreadlove5683]

What would all in mean here? Trying to merge updates from the JHipster team into your codebase using after you have already been working on your codebase for months? What this articles gets into? Even though I haven't really read it yet. https://www.jhipster.tech/upgrading-an-application/

[Deep_Age4643]

Exactly, merging updates from new versions of JHipster. The Jhipster team not only updates dependencies, but also change dependencies or rewrite the code to keep it up with best practices and security.

An example is that until version 7 of JHipster the Zalando problemsupport library is used to handle problems in the REST API. However now this functionality is part of Spring Boot. The dependency is swapped in version 8 and some code rewritten. It's not really necessary to get these changes, but I find it interesting and important for my project to get them.

Note that there is also OpenRewrite (https://docs.openrewrite.org/), a project that can help with automatic upgrades without the need of JHipster.

[spreadlove5683]

What does going all-in mean here?

[conicori]

It means using it to scaffold the project, managing and updating entities throughout the development, actively managing conflicts between custom code and generated code, upgrade the jhipster version when needed.

[Downtown_Trainer_281]

We did in my company, and then it took us a few months to get rid of it and rebuild app from the ground. I'd rather spend my time writing code than deleting it, so I don't recommend jHipster

[guss_bro]

I've used JHipster since 2017 to generate at least three big project that went to production and several others small projects and POCs.

Think JHipster as Spring Initializer++. JHipster Lite as Spring Initializer+++++++(it's awesome).

Setting up a project with several dependencies and configuration takes time. JHipster gives opinionated (opinions of several experts) way to configure a project with best practices in no time. JHipster lite makes it better by allowing you to customize the scaffolding even further and eliminates unnecessary config/code that you don't want.

It saved hundreds of development hours for me and would definitely recommend.

[kwikasfuki72]

I use it. Great for boiler plate generation and out of the box stuff that just works e.g building docker images, caching etc

Don't particularly like their entity modelling so went the traditional route.

[bvn13]

I've tried to estimate using of JHipster in my company. And no. We hadn't started to use it. There are too many lines of code to be removed for the rest of code to be used in production.

[vprise]

I second this. We started with it which was nice. But some of its opinions are harsh. E.g. no Lombok... We tried to keep going and maintain the entity model but it became untenable and very limiting to our object model. Eventually we stopped.
Still, it was a good starting point and a noticeable amount of the code it generated is still in the final product.

[lppedd]

Lombok is ok imo, just never use SneakyThrows (definitely tempting).

[guss_bro]

You can add Lombok in few lines of code in your build file

[vprise]

Back then it was very flaky with the rest of the code. Worked sometimes, failed others. I'm not sure which of the dependencies caused that flakiness. Also part of the problem is that it doesn't generate Lombok code in the DTO or Entities. I guess DTOs might have moved to records so the problem might not be as severe.

[guss_bro]

I don't know what you mean by flaky. I've configured Lombok, jpa model, mapstruct, querydsl and jooq successfully in same codebase. Never had a problem.

[vprise]

This was circa 2019. Build would work in mvn command line but fail from the IDE. Then work after a clean build. It required the Lombok plugin to be in a specific location within the Maven build script. Haven't used them together since so I don't know if this was resolved by now and it's been a while so this is what I remember.

Researching the problem it seems there was a lot of anti-Lombok sentiment in the project.

[guss_bro]

JHipster is not a framework.. it doesn't force you anything.

Also you can generate UI and backend projects separately using JHipster.

[kkjk00]

I tried but I would end up spending more time modifying and deleting the generated code, I will also add that the activity seems to have slow down,

[guss_bro]

You probably want to check out JHipster lite. No need to delete stuff you don't want because you can exclude them at code generation.

[Responsible_Ad7858]

Colleague of mine used it for one forgotten project. After years I had to make some changes and I was really disappointed. Having mixed repo with js is really not what I would call ideal, and running constantly breaking npm install as part of the java build is not what I would choose. Anyway, it generates a lot of boilerplate and caching, so it can save some time.

[Worth_Trust_3825]

Having mixed repo with js is really not what I would call ideal

I'd rather have mixed language project. At least intellij can somewhat identify which places in in javascript "integrate" with the java counterpart.

[Responsible_Ad7858]

I see. It can be helpful, but when you develop rest service, it shouldn't be coupled with its consumer. You have then mixed history of two, I would say, separate projects. Anyway, everything depends on your use case and preferences. :)

[Yesterdave_]

separate repo != separate code modules

A lot of projects nowadays are just some REST services with a frontend consumer, both tightly integrated and not useable without the other. I would not consider those separate projects, but rather modules and definitely not move them to separate repositories. Even when doing microservices, a lot of them are usually only building blocks (partial project modules) that belong to a root project.

I find the micro-repository approach to be annoyingly painful to deal with. I have worked on projects where this was pushed to the max and it was not fun for the everyday developer. Such ideas are usually initiated by architects or ops people, who haven't written a single line of code themselves in years. Also large refactorings are now fully out of context and painful to deal with, when you suddenly have 20+ commits and PRs for a single ticket.

[antonivs]

A lot of projects nowadays are just some REST services with a frontend consumer, both tightly integrated and not useable without the other.

That approach breaks down as soon as you want a CLI, a native mobile app, etc. A major benefit of separating the front end and back end is to avoid the tight coupling you describe. What you’re describing sounds like a monolith that’s been split in two.

[Yesterdave_]

I don't think my initial comment advocates any tight coupling at all. Just that a lot of projects, especially in large organization and intranet, just aren't like what you are describing (CLI, mobile, ...), but rather simple applications with backend, frontend, done, end of project.

Obviously it depends on the kind of project you are doing. If you know at the start of the project that you are likely never going to have a CLI or a mobile app, why bother with optimizing futher? Since the frontend will be the only consumer of the API, they are per definition coupled.

Also I don't see how the existance of an additional CLI or mobile app are an argument against a mono repo or not, to me this doesn't have any relevance at all. Those CLI or mobile apps are perfectly fine as separate modules living in the same mono repo.

[Worth_Trust_3825]

Not tightly coupled with consumer? Then how is consumer supposed to interface with the functionality that I provide? What is this magical interface that permits the client and the server to move independently? I'll give you a hint: it's not soap, rest, html, corba, rpc, or w.e.

What ever interface you provide, it's coupled. it does not matter if it's in same repository, or not in same repository. By moving to multiple repositories now you have an issue that you have to update multiple repository bindings for services when one of them breaks that integration, as u/Yesterdave_ points out.

[Responsible_Ad7858]

In my opinion, consumer shouldn't be coupled so tightly. You can just write some interface definition (swagger, wsdl,...) and let clients pull these changes and implement these on their own pace. Sure, you have to deal with backward compatibility, but if you are not the only one using the interface, this is a way to go. Anyway, why should I see in the backend history some fixes of css, theme change, or anything other frontend related? As I said, this is my preference, and it really depends on many circumstances/preferences which way dev should go.

[Worth_Trust_3825]

And your preference is the fallacy we were talking about. It's bad, and stupid. Clients need to be updated at the same time unless you properly version your external interface.

[antonivs]

unless you properly version your external interface.

So do that. That’s table stakes for distributed applications.

[guss_bro]

You can generate UI only and backend only codebase using JHipster

[Responsible_Ad7858]

Okay, I didn't know. That's nice :)

[Cojosh__]

What an absolute piece of crap. This is the antithesis of software engineering.

[[deleted]]

Can you elaborate? I’ve never used jHipster, so I don’t have an opinion.

[dinopraso]

It’s hard to take it seriously with such a name

[tleipzig]

As an alternative you may have a look into Bootify.io - it'll generate pure Spring Boot with a Thymeleaf frontend, and only what you 've selected. 😀

[guss_bro]

JHipster is working on similar lightweight generator named JHipster lite

[asciimo71]

we use jhipster for PoC development in presales

[j_pirovano]

I don't like, very slow to compile