RestyGWT frente a RequestFactory

Question

Estoy pensando en migrar mi capa de servicio actual basada en GWT-RPC a otra cosa. Se trata de 10 interfaces de servicio con 5 métodos cada una, y que involucran alrededor de 20 entidades de dominio diferentes, por lo que tiene una idea de la cantidad de trabajo que requeriría cambiar todo, lo que obviamente me gustaría minimizar. También estoy usando Gilead y un Servlet centralizado basado en Guice para manejar todas las solicitudes de RPC.

Las principales razones para el cambio son:

• TypeSerializers están consumiendo la mayor parte importante del tamaño del código de la aplicación.
• La serialización/deserialización en el lado del cliente es LENTA especialmente en el modo dev, lo que parece ser un hecho común con GWT-RPC.
• Obviamente, me gustaría minimizar la carga útil en el cable, pero no es un requisito difícil.

Las opciones que estoy pensando son:

• RequestFactory, que se promueve como una bestia más rápido. Pero me temo que sería mucho trabajo reemplazar todas las referencias en el código del cliente de objetos de dominio por sus contrapartes de proxy, y también soy perezoso para construir realmente todos los proxies.

• Un enfoque JSON/REST completo usando RestyGWT, que parece que me permitiría seguir usando los objetos de dominio, pero me temo que terminaría con una deserialización aún más lenta? No estoy basado en ningún hecho, pero no pude encontrar ningún tipo de referencia. Es solo una impresión.

Realmente me gustaría obtener sugerencias.

Gracias!

Answer 1

Aunque actualmente estamos trabajando con RequestFactory, estoy recomendando REST. Estas son las razones principales por las 3: implementaciones

1. cliente y servidor no tienen que ser dependiente (si alguna vez planea en aplicaciones nativas para un dispositivo Android que no se olvide de RequestFactory).
2. nuevos cambios API en código de cliente vieja de la rotura RequestFactory (esto tiene resultados devastadores en la producción)
3. el sistema ecológico de descanso y las comunidades son más grandes y es más fácil para hacer frente a los problemas en el código, y permitir que otras aplicaciones se comuniquen con la suya en el futuro.