Release blog post: What's new in Hilla 2.2: React form hook and hot reloading
BrowserCallable 
HillaEndpoint would be more appealing 
I like Endpoint because this is what it is and my classes have the suffix Endpoint. I’ll never annotate a service. A service is often used as a DDD service
Agree, the same goes for repositories for me - single responsibility principal. The least functions a class has, the better
Endpoint in Hilla IMO is the same as the Controller in MVC
It’s there now as an experiment to gather feedback. Not planning on deprecating or removing @Endpoint.
What we’re trying to see is if we could find a better name that helps developers understand Hilla better. We have seen many cases where the Endpoint association makes developers think of REST endpoints, reusable services that should be callable from any client. Some adding RestController annotations for get and post mappings and parameters.
Unlike a RestController, a Hilla endpoint/service (name tbd 
) isn’t a way to transform Java method calls to HTTP verbs, status codes and serialized data. We want developers to be able to call their “services” directly.
But it sounds like this suggestion isn’t making things better in your mind. Any thoughts on how we might convey the ideas more clearly?
Also: thanks for the direct feedback, this type of discussion is what we need 
I understand but it’s still an API. And in a good architecture -style this still be separated from business logic. Also exposing Entities is not a good style.
HillaEndpoint could be a better name.
In terms of Entities you will have lazy loading exceptions or does Hilla implement the open session in view (anti-) pattern?
I agree with everything Simon said 
(I also like the name more)
Got it. When you’re building Flow apps, what kind of API do you define between your UI code and services to separate the UI from business logic?
(thinking if there might be some good parallels we could draw)
I’m normally working with dedicated services for specific domains (like customers / products and so on) those services have business objects… this services are the core of my design and are responsible to call other services, mapping business to entities and calling repositories. (Often the service is an interface which has multiple implementation for test or production where it e.g. is just a rest client calling other apps… or it has a in memory storage)
In your Vaadin Flow view code, do you call these services directly, or do you have some kind of controller, presenter, etc in between? (I’ve seen many different takes on this over the years)
I’m calling / injecting this service directly - this makes the code in my opinion easier to understand before I create multiple classes for nothing, because business logic is already in the services
Ok. That is kind of what we were going for with this annotation. As we consider the frontend and backend to to be part of the same full-stack application. The assumption being that the service would return some kind of DTOs, not entities. But we clearly have work to do here still 