RestyGWT против RequestFactory

Я думаю о переносе моего текущего уровня сервиса на основе GWT-RPC на что-то еще. Это около 10 сервисных интерфейсов по 5 методам каждый и включает около 20 разных доменных объектов, поэтому у вас есть представление о том, какая работа потребует изменить все, что я хотел бы свести к минимуму. Я также использую Gilead и централизованный сервлет, основанный на Guice, для обработки всех запросов RPC.

Основные причины изменения:

  • TypeSerializers потребляют самую большую часть размера кода приложения.
  • Сериализация/десериализация на стороне клиента является SLOW специально в режиме dev, что, по-видимому, является общим фактом с GWT-RPC.
  • Очевидно, я хотел бы свести к минимуму полезную нагрузку на плате, но это не является жестким требованием.

Параметры, о которых я думаю, следующие:

  • RequestFactory, который продвигается как более быстрый зверь. Но я боюсь, что будет очень много работы, чтобы заменить все ссылки в клиентском коде объектов домена на их прокси-копии, а также я ленив, чтобы на самом деле построить все прокси.

  • Полный подход JSON/REST с использованием RestyGWT, который, похоже, позволит мне по-прежнему использовать объекты домена, но я боюсь, что это приведет к еще более медленной десериализации? Я не основываюсь ни на одном факте, но не смог найти какой-либо бенчмарк. Это просто впечатление.

Я действительно хотел бы получить предложения.

Спасибо!

Ответ 1

Хотя мы в настоящее время работаем с RequestFactory, я рекомендую REST. Это 3 основные причины:

  • Реализации клиента и сервера не обязательно должны быть зависимыми (если вы когда-либо планируете использовать собственные приложения для не-андроидного устройства, чем забыть о requestfactory).
  • новые изменения api в requestfactory разорвать старый код клиента (это имеет разрушительные результаты при производстве)
  • система REST eco и сообщества больше, и легче решать проблемы в коде и разрешать другим приложениям общаться с вами в будущем.