Following the hypersistence recommendations, we have set the Hibernate fetching of ManyToOne and OneToOne relationships to LAZY. This has the side effect that those relationships are not fetched in the REST API either and thus, they are not rendered in the front-end.
So I think we should have a clear strategy on what we generate for the fetching of relationships:
id
, the fetching can remain lazy.Any thought ?
I'm in favor of following the recommendation and keeping it LAZY. The way I would like to do it is to force the DTO option in JHipster and depreciate the entity option that doesn't use DTOs. This would ease maintenance for us and also enable Mapstruct by default like we wanted to do.
Other things that I'd like to have:
This could be a complete rework of the back end entity generator for JHipster 7. Also integrating spring hateoas by default.
If we where to do that much work I would go for the graphql way. This goes for both the Hateoas part and lazy/eager loading of entities/relationships.
IMO Graphql cannot be a full replacement of REST, it could be an alternative option. And I don't want to lose swagger.
graphql has it's own swagger, https://github.com/graphql/graphiql
Why do you think, graphql can't replace REST, everything custom you are doing with REST (example update a subset of entities, calculate custom aggergate value....) can be done in graphql with a custom mutation our varaible name only thing that changes, is the endpoint hat receives the query, and everything is done using POST(or GET)
Have you used Graphiql ? It's awful, it doesn't show errors consistently (ie. Http status). Then with Graphql security and caching is a headache. But of course it's interesting for many use cases !
@PierreBesson aren't we facing the same issues today with swagger, and are overriding the swagger code in every jhipster project? (I love swagger for REST but I don't think we can/should discard grahql and all of it's benefits compered to REST because of a Tool, + tools can be improved...)
GraphQL should not be the subject of this ticket.
Anyway, it has been asked several time but no one wants to code and maintain a module for that, to see if it's popular... So @yelhouti if you're motivated and have the bandwidth, you're really welcome to code a module. I'm pretty sure it can become popular and then, we can reconsider to include to main generator jhipster
@pascalgrimaud I guess you are right, I was trying to join efforts since both this issue and graphql go in the same direction. I'm already maintaining two blueprints, and If I have to work on a GraphQL I would certainly need some help, specially On the caching/persistence part.
Not trying to de-rail the issue further, but we should probably open a separate conversation about GraphQL and QUIC/HTTP3 and how to move the ball forward for JHipster 8.
The reason we need to discuss them together is the underlying effects HTTP3's ratification will have on Spring Boot's APIs and the underlying data serialization. GraphQL is already a big module to build, and right now seems like the "between a rock and a hard place" stage given it's likely a lot of it would have to be rewritten for HTTP3, or worse, written twice with double the maintenance overhead for HTTP1/2 and 3.
On the main topic, I support keeping it lazy by default AND moving off the Entity system to DTOs. As for fetch customization, there are a couple bulky/painful ways around needing GraphQL, but they require we either implement both lazy and eager fetching APIs, or we just add the Eager param to all of APIs and then make the final call at the Service layer based on the value.
One other option would be to use API Chaining, but this is pretty exotic and primarily a latency-hiding technique built for problems primarily experienced by people who already run the best networking infrastructure in the business, like Amazon. It's also very different to how JHipster APIs are currently structured. https://github.com/mikestowe/REST-API-Multiple-Request-Chaining.
And I suppose a third option could be that we extend the JDL to include an 'eager' variable which 'false' by default and then have JHipster's generator implement accordingly.
And sorry to continue the tirade...
My main concern about stamping out hyperlinks for xxxxToMany relationship fetches is effects on distributed database apps. When UUID is used instead of ID, or the relationship is on other keys, can we stamp out these hyperlinks consistently?
Also, from a security perspective, exposing actual row IDs in hyperlinks isn't best practice against cross-site scripting attacks, potential attacks by screen capture vectors, etc.. Could we easily obfuscate the IDs with a hash based on the Session ID, User ID, or another consistent, non-trivially-predictable source? Domain APIs are one thing; but it's the unfortunately annoying, nitty-gritty stuff like this that limits JHipster adoption in more conservative business environments (as someone who worked in financial service IT and had to obfuscate any Personal Identity Information such as employee IDs in URLs for regulatory reasons).
what should we do for this ticket ?
maybe stay like this, and the end user can custom, according to the needs ?
As there is no comment on this since months, let's stay like this today and close this ticket.
Don't hesitate to comment if you think there is something to do/improve, so we can reopen the ticket.
Most helpful comment
Other things that I'd like to have: