Should a user use generator JHipster or JHipster Lite?

[Hippolyte Durix]

Hello folks,

We've started an illustration for JHipster's users to be able to choose between generator JHipster and JHipster lite when generating a project.

For us, both solutions cover different needs, that's why it seems important to explain what kind of generation needs each one resolves.

The main goal would be to show it on the JHipster lite readme.

What do you think of that? Do you agree with that?

Hippo

[Matt Raible]

Hi team!

In my experience, it’s really hard to market two products that kind of compete with each other. I created AppFuse Light (https://github.com/appfuse/appfuse-light) back in the day based on user requests. Then, no one ever used it. 

We’ve had a similar issue at Okta with Okta Customer Identity and Auth0. We’re currently in the process of making changes to lead with one instead of leading with both. Our buyers and salespeople were confused with the choice and we never gave them a clear path on when to choose which product. I like this diagram because I believe clear direction is important for our users.

I think we should still lead with JHipster, because there’s a huge community around it, including books, tutorials, sponsorships, etc. And we shouldn’t call it “Generator JHipster” because that name is mostly internal and not recognized by our community. 

I think we should change a few things in this diagram to make JHipster look better. IMHO, JHipster Lite is very beneficial to people working on the project itself, but not as great for our end users. 

1. I want to build a complex CRUD app (since JDL allows this and goes way beyond “simple”). Or we could just say “I want to build a CRUD app" and leave adjectives out of the statement. 

2. I want to build a demo application. I think JHipster demo’s very well in front of meetup and conference audiences, as well as in YouTube videos. I get a low of “wows” from developers whenever I do demos and I think demo is a better term than disposable. 

3. I don’t know that design around infrastructure makes sense. It might make more sense to emphasize JHipster’s microservices support and how to you can easily deploy it with Kubernetes. I propose changing #3 to “I want to develop a microservices architecture”. 

And we shouldn’t forget all the blueprints that we’ve been updating recently. What if the user wants to use Kotlin, Ionic, React Native, Spring Native, or even Micronaut/Quarkus? In theory, if JHipster Light has the same endpoints, the mobile blueprints should work with it. However, there’s typically not much to demo if there’s no CRUD to show on the generated app. 

Cheers,

Matt

On Sep 7, 2022, at 08:46, Hippolyte Durix <hippoly...@gmail.com> wrote:

Hello folks,

We've started an illustration for JHipster's users to be able to choose between generator JHipster and JHipster lite when generating a project.

For us, both solutions cover different needs, that's why it seems important to explain what kind of generation needs each one resolves.

The main goal would be to show it on the JHipster lite readme.

What do you think of that? Do you agree with that?

Hippo

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAPZPDN-ymhO3pEtu_oACqE%3DUfrB4eCfP_D6yniGniug7NX73sQ%40mail.gmail.com.

[Julien Dubois]

Hi everyone,

I totally agree with Matt on this.

It’s impossible for JHipster Lite to compete with JHipster, there is just so much work, by so many people. There are books, indeed, but also years of stack overflow questions and chats, mailing list discussions, etc etc.

There is one thing, mainly, that is at the core of why people use JHipster: it’s the JDL. My goal would be to have JDL support for both “classical” JHipster, JHipster Lite, and in fact any Spring Boot application that has Hibernate.

This isn’t that hard to do, and would build a bridge between both apps. I’m just worried that the hexagonal architecture pushed in JHipster Lite will make it much more complex for many people. I’m also not convinced it will work well with Hibernate (that’s a long story, and not the right place here to discuss this).

I’m going to do 2 talks on JHipster Lite in the next couple of months: one at Devoxx Belgium, and one at the Paris Java User Group. Those will be great moments to gather feedback.

While I’m preparing for those, I’m also having a lot of feedback by myself -> I’ll start another thread on this.

Julien

On 7 Sep 2022, at 17:44, Matt Raible <ma...@raibledesigns.com> wrote:

Hi team!

In my experience, it’s really hard to market two products that kind of compete with each other. I created AppFuse Light (https://github.com/appfuse/appfuse-light) back in the day based on user requests. Then, no one ever used it. 

We’ve had a similar issue at Okta with Okta Customer Identity and Auth0. We’re currently in the process of making changes to lead with one instead of leading with both. Our buyers and salespeople were confused with the choice and we never gave them a clear path on when to choose which product. I like this diagram because I believe clear direction is important for our users.

I think we should still lead with JHipster, because there’s a huge community around it, including books, tutorials, sponsorships, etc. And we shouldn’t call it “Generator JHipster” because that name is mostly internal and not recognized by our community. 

I think we should change a few things in this diagram to make JHipster look better. IMHO, JHipster Lite is very beneficial to people working on the project itself, but not as great for our end users. 

1. I want to build a complex CRUD app (since JDL allows this and goes way beyond “simple”). Or we could just say “I want to build a CRUD app" and leave adjectives out of the statement. 

2. I want to build a demo application. I think JHipster demo’s very well in front of meetup and conference audiences, as well as in YouTube videos. I get a low of “wows” from developers whenever I do demos and I think demo is a better term than disposable. 

3. I don’t know that design around infrastructure makes sense. It might make more sense to emphasize JHipster’s microservices support and how to you can easily deploy it with Kubernetes. I propose changing #3 to “I want to develop a microservices architecture”. 

And we shouldn’t forget all the blueprints that we’ve been updating recently. What if the user wants to use Kotlin, Ionic, React Native, Spring Native, or even Micronaut/Quarkus? In theory, if JHipster Light has the same endpoints, the mobile blueprints should work with it. However, there’s typically not much to demo if there’s no CRUD to show on the generated app. 

Cheers,

Matt

On Sep 7, 2022, at 08:46, Hippolyte Durix <hippoly...@gmail.com> wrote:

Hello folks,

We've started an illustration for JHipster's users to be able to choose between generator JHipster and JHipster lite when generating a project.

For us, both solutions cover different needs, that's why it seems important to explain what kind of generation needs each one resolves.

<image.png>

The main goal would be to show it on the JHipster lite readme.

What do you think of that? Do you agree with that?

Hippo

-- 
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAPZPDN-ymhO3pEtu_oACqE%3DUfrB4eCfP_D6yniGniug7NX73sQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/B46A3D8B-A985-4632-A723-A2EE8EAA5D1E%40raibledesigns.com.

[Deepu K Sasidharan]

I also agree with Matt here. We should clearly show when to use JHipster vs JHipster lite. I also agree we shouldn't make it sound like they are competing, as both produce different outputs and are more suitable for different use cases.

IMO JHLite might be more attractive to power users and experts while JHipster being more attractive to beginners and medior to senior devs. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/8F2DD875-DD8A-4549-B30A-551EEE8F3DB0%40gmail.com.

[Matt Raible]

A quick question: does JHipster Lite support microservices?

I’m doing a speaking tour next week in Ireland. I’ll be talking about our microservices and micro frontends support. I’d like to mention JHipster Lite. I want to make sure I properly talk about its capabilities when it comes to microservices and micro frontends.

Thanks!

Matt

[Julien Dubois]

Hi Matt,

I’m still learning it for my Devoxx talk :-)

So yes there is Eureka support, and you can probably make something very similar to what we have for JHipster. There are 3 differences in my opinion:

- As it generates something much more modular, “à la carte”, you could have a lighter micro service, which is good for micro services

- It doesn’t have the level of integration that we have in JHipster. I don’t think you would have JWT token relay as of today. I might be wrong, and this wouldn’t be hard to do, so at the minimum it’s just a matter of time to have feature parity on this

- Micro front-ends are far from being ready. It’s “only” generating basic front ends with the CLI from each client side library (Angular CLI, Vite, etc). It might be better for some people, but not for micro front ends.

Julien

[Pascal GRIMAUD]

Hello,

Before leaving my company, we used JHipster Lite to generate 3 microservices for my customer.

All these applications were deployed in production, using:

- Consul

- OAuth2 with Keycloak

- these applications can communicate with the other ones (generated with the classic generator-jhipster)

So I confirm these different modules/features (Consul + OAuth2) work well.

I plan to open a ticket to test it with Okta, but it shouldn't be an issue.

Pascal

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/AFA89E4C-CC82-432B-B1F7-259CCF3A55CF%40gmail.com.

[Matt Raible]

Great! Thanks for the quick feedback y'all! 

On Sep 22, 2022, at 00:52, Pascal GRIMAUD <pascal....@gmail.com> wrote: