A few days ago I\'ve started developing a Backend for Mobile Applications using Google App Engine and Google Cloud Endpoints. This tutorial shows how the endpoints are getting g
Maybe i don't understand something. But everything seems (for me) to be very easy.
GWT (client!) is not on the server. It is compiled Javascript executed in client's browser.
Google plugin generates Javascript client code that calls Endpoint with suitable JSON.
Above code can be called from GWT.
Voila?
The good old DTO dilemma. There is no right or wrong, just what is good enough for you.
Repeating yourself can be a good thing. Right now you are exposing your data model through your endpoint, which means that any change of your Entities will impact your mobile app users. Let's say you rename an attribute on the server side -> every client who has not updated the app goes down.
Security is also an issue : if your User entity has an "email" property, serializing it through GWT RPC will make your user's email virtually available to any javascript debugger.
Is it really what you want?
Don't get me wrong, I'm not a fan of those "onion layers" monster apps where 80% of the code seems to be made to transform objects into other objets with virtually the same properties.
I think the right solution is in between: having a "client" model (DTOs), made of serializable POJOs (no datastore, ORM, JAXB, whatever annotation) that you expose through both GWT RPC and Client Endpoints. Your GWT servlet implementation and the Endpoint server would call the same service that will transform your client model into entities and process/persist them.
This way you can reuse your code, still keep it simple, have a uniform interface accross your APIs, and allow your inner plumbering to evolve without altering the client interfaces.