Ability to skip layers and REST methods

[deepu105]

Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate.

Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL

This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster 😢 I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application)

something like this (ping @MathieuAA )

@skipResource | @skipService | @skipRepository | @skipDto | @skipClient
@skipRestMethods(PATCH, DELETE)
entity Product {
}

WDYT @jhipster/developers

[pascalgrimaud]

My idea would be to have different sub generators:

• domain : it will create a domain object, like it's done in an Hexagonal Architecture
• service: related to domain
• entity: it will create the @Entity with repository, with mapper domain <-> entity
  • entity-sql
  • entity-mongodb
  • entity-cassandra
  • etc.
• resource: it will create the resource, according to your config
  • resource-mvc
  • resource-webflux

These sub generators can be composed with Yeoman.
By using this kind of architecture, you can use separately if you want. Each sub generators can be in a separated pull requests in real projects.
The pre-requisites would be the "domain" (which is not the same definition like the domain we have today)

So instead of skipping stuff, I'd prefer:

domain Product {
...
}

resource-mvc product
service product
entity product

If you want the domain object and the entity:

domain Product {
...
}

service product
entity product

Later, we can have a Kafka consumer instead of resource:

domain Product {
...
}

kafka-consumer product
service product
entity product

[MathieuAA]

Hello Deepu! This solution could work but instead of skipping, I'd rather take the opposite approach (the rails one): select what should be generated instead of what should be skipped.
I have to assume users know what is generated and also know what they don't want.
For the users who want the "whole package", I guess the skipping could be useful.

[pascalgrimaud]

This solution could work but instead of skipping, I'd rather take the opposite approach (the rails one)

I'm faster than you @MathieuAA 🍻

[deepu105]

Hey both, yes that was my first thought as well, but then I started thinking about our average users who want us to provide an opinionated defaults. What you are suggesting would be good for power users and senior devs, but for someone using JHipster to learn or to quickly get something with all bells and whistles, it would be lot of friction for them to pick and choose everything.

IMO, the success of JHipster is mainly due to the fact that we cater to not-so rock star devs (average devs) and we provide an opinionated stack where everything works so IMO, JHipster by default should still be providing fully working CRUD apps and provide ability for power users to customize and pick and choose

So I don't care if it is by exclusion or inclusions as long we dont force everyone to pick and choose all the time

[pascalgrimaud]

Yes, the goal would be to keep the behavior like today, and it should not change :

• generate the full application with these options by default

Only, the internal stuff must change:

• splitting entity-server sub generator into smaller sub generators
• we already did the work with entity-client, entity-i18n, etc, but IMO, it's not enough
• having this kind of template is impossible today to maintain correctly: https://github.com/jhipster/generator-jhipster/blob/main/generators/entity-server/templates/src/main/java/package/domain/Entity.java.ejs#L242-L269
• I can't touch this file without testing: reactive, mongodb, neo4j, etc etc etc... because it is SOOOO complex !
• it's far better to have smaller sub generators like:
  • entity-sql
  • entity-mongodb
  • entity-cassandra
  • etc.

[DanielFran]

We should keep the behaviour as is today in V7, and maybe switch only in V8 with the 'hexagonal' approach

[pascalgrimaud]

no need to wait v8, it can be done progressively. I already have small sub generators:

• init project : it generates default files like gitignore, editorconfig, package.json with prettier etc
• maven: add wrapper, init default pom.xml etc
• spring boot: add minimal spring boot dependencies

By composing these 3 sub generators, it's similar to what we can have with Spring Initializr, but it's better (because of editorconfig, prettier)

By composing the init+maven, I can build a java library (already used for my current customer)

These sub generators are like module in fact, nothing new here

[mshima]

Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate.

Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL

This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster 😢 I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application)

@skipResource | @skipService | @skipRepository | @skipDto | @skipClient
@skipRestMethods(PATCH, DELETE)
entity Product {
}

By the way this is already somewhat supported.
Since dto and service are disabled by default this should work:

@Service(serviceClass) @Dto(mapstruct) @SkipClient
entity Product {
}

[deepu105]

Yes I know about those, well I added those originally 😜, but this is to take it even further so that we can do the same for other layers as well. Probably this is in line with what Pascal has in mind as well. So lets wait for his full proposal.

…

On Mon, 22 Mar 2021, 6:47 pm Marcelo Shima, ***@***.***> wrote: Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate. Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster 😢 I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application) @skipResource | @skipService | @skipRepository | @skipDto | @skipClient @skipRestMethods(PATCH, DELETE) entity Product { } By the way this is already somewhat supported. Since dto and service are disabled by default this should work: @service @dto @SkipClient entity Product { } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14416 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKF33S3DD6LZLDAV4VBDTE57B5ANCNFSM4ZTOW7XQ> .

[Tcharl]

So what should be the list of filters?

//Skipping layer
@SkipFaker
@SkipEntity // would result in a `List<DTO>` or `@Cacheable` in service
@SkipRepository
@SkipDTO // would result in exposing the entity to controller
@SkipService 
@SkipController // No Front? No Back ITest, No Front ITest
@SkipClientService // No Front
@SkipForms
@SkipBackUnitTests
@SkipBackITests
@SkipFrontUnitTests
@SkipFrontITests

/* Question: what is the impact of each Skip compared to the other layers? */

// Skip capability
@SkipSearch
@SkipCache

//Skip entity capability
@SkipMutate
@SkipCreate
@SkipDelete

Something else? If so please copy paste and complete the list!

[Tcharl]

Me again :-),

I'm also in favour of the first suggestion of @pascalgrimaud (inclusive option) instead of using skip*: I think that this is the only solution to keep being consistent across all options.

No mention => Jhipster reasonable default.
Mention => user defined behaviour.
Just have to explain this in the doc :-)

Specifying like this will permit to keep being consistent between binary and unary options.

service * with serviceImpl except X,Y,Z (impossible to achieve with a skip* because of the choice that has to be made between serviceImpl and serviceClass)
service * except X,Y,Z
controller A, B, C
controller * except X, Y, Z

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[deepu105]

Keep open

…

On Fri, 4 Jun 2021, 2:25 am github-actions[bot], ***@***.***> wrote: This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs 😃. Comment or this will be closed in 7 days — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14416 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKFY6WIAQL7FMWWXFKV3TRAMQZANCNFSM4ZTOW7XQ> .

[ivanmonteiro]

Yes, the goal would be to keep the behavior like today, and it should not change :

• generate the full application with these options by default

Just my thoughts as a blueprint developer: This seems ok and possibly It would be the frictionless way not requiring many changes to the blueprints.

Only, the internal stuff must change:

• splitting entity-server sub generator into smaller sub generators

Blueprint developers could (maybe optionally?) implement the sub-generators to allow skipping.

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[Tcharl]

Keep open

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[Tcharl]

See RFC: #18152