App Engine - RequestFactory vs servlets vs other approaches

Question

Nuestro equipo está trabajando en la aplicación de Android con App Engine. Tenemos algunas diferencias en las opiniones con respecto a la implementación de la comunicación cliente-servidor. Por un lado App Engine sugiriendo enfoque RequestFactory, que (como Google dicen)

provides a solid foundation for automatic batching and caching of requests in the future

y light-weighed

Pero nos encontramos con este enfoque un poco "torpe". Por otro lado, podemos utilizar un enfoque de servlet común que conocemos bien y con el que nos sentimos más cómodos. Deseamos encendedor, más rápido y comunicación escalable, pero ¿en qué proporción RequestFactory realmente los proporciona? Qué más podemos ganar y perder de ambos enfoques.

[Más de eso, leemos sobre opciones como GWT-RPC (una versión anterior de RequestFactory) y RestyGWT. Pero sabemos poco acerca de estos enfoques y no estamos seguros de si se ajustan a nuestro caso.]

Encontré aquí algunas preguntas similares sin respuesta. Entonces, supongo, esta puede ser una discusión útil para muchos.

Answer 1

Unas pocas notas:

1. RequestFactory no es parte de App Engine (ver here), sino un complemento introducido por el plug-in de Eclipse Android. Originalmente RequestFactory se creó para GWT.

2. El aspecto positivo de RequestFactory es que funciona a la perfección con GWT y Android.

3. La desventaja es que no es multiplataforma, es decir, no está disponible para iPhone, etc ..

4. No está claro cómo RequestFactory versión. Si su aplicación es grande y evoluciona, está obligado a tener dos o más versiones de API de RPC que atiendan a los clientes. Los clientes de GWT pueden verse forzados a usar la API más nueva (= carga de página), no así con Android. AFAIK, no hay opción de tener dos extremos de RequestFactory. Con REST, simplemente puede tener múltiples URL para diferentes versiones de API.

5. Mezclar API públicas/privadas. Como no hay puntos finales múltiples de RequestFactory, no puede dividirlos fácilmente en públicos (no se requiere autorización) y en privado/seguro (= se requiere autenticación). Con REST (y GWT-RPC) puede simplemente tener dos servlets (privados y públicos) y establecer restricciones de seguridad en web.xml (o tener su propio filtro de servlet).

6. RequestFactory no es compatible con java.util.Map. Esto limita severamente la capacidad de tener entidades con propiedades dinámicas; hay soluciones para esto, pero son IMO un kludge innecesario (como tener dos listas, una para las claves y otra para los valores).

Solución: Esta es una solución que utilizo en mis proyectos:

1. Crear una capa de servicio que devuelve objetos de dominio POJO.

2. Crear capa de RPC que llama a la capa de servicio. Puede tener varias tecnologías RPC que llamen a la misma capa de servicio. Normalmente tengo GWT-RPC y REST.

3. El uso de objetos de dominio solo de POJO a veces es imposible (también debido a JPA/JDO), lo que le obliga a crear DTO. Los DTO son difíciles de mantener e intento evitarlos si es posible. Es posible usar objetos de dominio la mayor parte del tiempo con algunas soluciones: en App Engine puedes obtener mucha ayuda usando Objectify en lugar de bajo nivel/JPA/JDO. Es supports GWT-RPC. Con REST, sugiero que use Jackson, donde can do all kinds of custom conversions.