Interesting discussion, and agree completely with the argumentation around security/excessive data transfer mitigation. @HillaEndpoint gets my vote.
What about @JsonView? https://github.com/vaadin/hilla/issues/1067 clams that it’s a “widely accepted” alternative to DTOs
Never used that. I prefer DTOs because it’s self documenting. (plus, I’m not a fan of annotations). And with Java Records it’s simple
Same as Simon, never used it before. It looks interesting, but I also prefer dedicated classes for dedicated jobs / endpoints.
One of the challenges that we’re struggling with when using DTOs is that you have to put the validation annotations on the DTO in addition to the entity to have it generated into the TS.
First we say that you don’t need to do validation both in Java and TS, but then we say that you instead have to do it in Java and Java.
Personally, I’m against adding all those validation annotation on the entity class… in my opinion those should be part of the contract before the database is touched (there are only required, max length annotation from JPA)
This also allows for different validations for the same entity, based on different methods. Like one endpoint required something the other requires (add vs update for example)
@JsonView would circumvent that problem, but we’re also considering an option that would carry over validation annotations wherever there’s a property with the same name in the entity and the DTO
You can also use validation groups if you want different rules for different cases
Of course, this is not an issue if people are on average fine with not defining validation on entities. Maybe that’s something that you only do with Flow where you don’t need DTOs?
Yeah the bean validation is powerful, making it also really hard for Hilla to support all kind of caveats.
I understand your need to find a proper place for those validations and the first place that comes to mind to reduce the boilerplate would be the entity that is already there.
I’m not using entities on flow and also create DTOs there 
I have a strict layer in all application that aren’t play grounds… often we later change from a single boot app to later move the backend to another boot app and adding a rest service in between, with the dto approach already in place the whole migration from a fat jar to two services is done within the speed of your copy paste + creating a rest client / server for the DTOs (no change in frontend or backend logic needed because they are already de-coupled)
I rarely use Bean Validation. Except maybe NotNull which is a a replacement for Column(nullable = false). I also don’t like the BeanValidationBinder because it takes the property name as string. I prefer explicit validation in the UI layer. Additionally I use jOOQ instead of JPA wherever I can.
Same here with Bean Validation. But it’s probably the best tool for the job in Hilla (please don’t create your own framework) with all it pros and cons.
Oh sure! It’s the J(whatever) EE standard and should be used, absolutly!