I have to sign off now as I have an early morning flight, we’ll have to continue another day. Thanks again for all your input, much appreciated 
Have a good flight! Probably a good discussion topic in October 
Safe travels!
Now I understand where the idea for BrowserCallable comes from 
Do you see a difference in a Flow Java view and a Hilla React view and what they should or should not call? Why?
For me it’s a fundamental difference, with flow I can be a little bit more careless about my services and add methods which I call internally but are never exposed to the client side. With Hilla this drastically changes and I have to make 100% sure that all methods in a class annotated by Hilla are allowed to be exposed because it’s easier for user to just call them via Javascript. That’s why I would always prefer a second layer “Hilla endpoint” over my normal service classes or even repositories. Additionally this also to also reduce the amount of data which is transmitted to the client, because normally entities / tables have way more attributes and relationships than normally needed. So a proper DTO / custom query / views / return objects (however you call them) is also needed in a typical app
What exactly would you do then in this “endpoint” layer?
Would you fetch “too much” data in the service layer and then filter it down later?
For a simple app yes, for more complex apps / data structures or high load… I would go with custom queries made by criteria builder that only returns the columns needed.
A more complex example:
HillaEndpointsFlights
List getFlights ()
A Flight is an aggregate of a plane, some passenger information and schedules - all with they own repositories or even they own external services. The service layer would make sure that the flight is correctly build from all those information.
This also ensures that only the dedicated flights API is exposed and everything else is internal and is not accessible from outside to reduce possible attack vectors
This service would also change internal database ID to something like a UUID to ensure the original hibernate long based IDs are not exposed. Additionally I would add the validations to this class instead of the entities for lose coupling, so that I can have different validations for different returns… e.g. a flight created by a normal user has only 100 passengers, but an admin has up to 200… (bad example)
This makes sense, once you add more methods to the mix… like edit with a EditableFlight object which has other validations and e.g. way more Attributes.
So you are basically saying you want a class (call it whatever you want) that is related to the particular view and returns data for that view in the format that the view expects and should have access to?
If you use Flow, do you bake this functionality into the view itself?
I bake this functionally (except validation because that’s done in the binder) also in the service class
My views are “dumb”
And yes! That’s exactly what I would do 
Yesterday, Simon called it controller from the old MVC pattern, this represents it good
I think the controller is a different thing. It interacts with services to populate a model for the view. I would rather use a phrase like “view service”.
I wrote a blog post draft around this topic that you can have a look at for additional insights: https://docs.google.com/document/d/1wJ77eUxeoRNsCF3-tCIOR-RfsL_isAMsJ2XPNTVFIOQ/edit
I’m fine with any name 
at least we mean the same thing / what it should do