GWT-RPC против HTTP Call - что лучше?

Question

Я оцениваю, есть ли разница в производительности между вызовами, сделанными с использованием GWT-RPC, и HTTP Call .

Мои сервисы appln размещаются в виде сервлетов Java, и в настоящее время я использую HTTPProxy-соединения для извлечения данных из них. Я рассчитываю преобразовать их в вызовы GWT-RPC, если это приведет к повышению производительности.

Хотелось бы узнать о плюсах / минусах каждого ...

Также есть предложения по инструментам для измерения производительности асинхронных вызовов ...

[ Хорошая статья о различных стратегиях взаимодействия с сервером , которые можно использовать с GWT.]

Answer 1

GWT-RPC обычно предпочтительнее, когда серверная часть также написана на Java, поскольку это означает, что нет необходимости кодировать и декодировать объект на каждом конце - вы можете просто передать обычный объект Java клиенту и использовать его там.

JSON (с использованием RequestBuilder) обычно используется, когда серверная часть написана на каком-либо другом языке, и требует, чтобы сервер JSON-кодировал объект ответа, а клиент JSON-декодировал его в JavaScriptObject для использования в код GWT.

Если бы мне пришлось угадывать, я бы сказал, что GWT-RPC также приводит к меньшим транспортным объектам, потому что команда GWT оптимизирует для этого случая, но любой из них будет работать, и JSON все еще может быть довольно маленьким. В большинстве случаев все сводится к удобству разработчика.

Что касается инструментов для измерения времени запроса, вы можете либо использовать инструменты разработчика Chrome / Webkit, либо расширение Firebug Firefox, либо измерить время запроса в вашем приложении и отправить эти данные метрик обратно на сервер в виде отложенного запроса на сбор и анализ. .

Answer 2

Я написал эту статью, упомянутую в вопросе (спасибо за ссылку!).

Как всегда, ответ «это зависит». Я использовал как GWT-RPC, так и JSON.

Как указано выше, GWT-RPC обеспечивает серьезную производительность при доставке Java-объектов (с некоторыми ограничениями) по проводам. Некоторой логикой можно поделиться, и GWT позаботится о том, чтобы маршалинг / демаршаллинг вашего объекта.

JSON допускает междоменный доступ и потребление другими, не GWT-клиентами. Вы можете обойтись с наложением типов, но никакое поведение (например, проверка) не может быть разделено. JSON также может быть легко сжат и кэширован, в отличие от GWT-RPC (последний раз, когда я смотрел).

Поскольку мы не знаем, какова полезная нагрузка, рекомендации по производительности сложно дать. Я бы порекомендовал (опять же, как кто-то делает выше) проверить себя.

Answer 3

Просто в дополнение к другим ответам, есть один момент, который может повлиять на ваше решение в отношении JSON, даже если вы используете Java на серверной части:

Возможно, когда-нибудь в будущем вы захотите разрешить клиентам, не являющимся GWT, общаться с вашим сервером. Многие современные сайты предоставляют некоторый доступ к API, и если вы используете JSON, у вас уже есть сравнительно открытый API.

Answer 4

В целом я согласен с Джейсоном - если ваша серверная сторона использует Java, используйте GWT-RPC. Вы сможете повторно использовать POJO, логику валидации и т. Д. RPC также имеет тенденцию лучше «играть» с MVP и разделением кода.

Однако, если ваша серверная часть использует что-то еще, используйте JSON - но не волнуйтесь, с Типами наложения JavaScript с использованием JSON очень просто. Вы не сможете повторно использовать код со стороны клиента на сервере (YMMV).

С точки зрения производительности - я бы сказал, что у JSON есть преимущество. Современные браузеры имеют несколько очень хороших методов для быстрого кодирования / декодирования для JSON. Я не уверен, что GWT-RPC «за кадром», но я сомневаюсь, что он может побить JSON, когда дело доходит до скорости. Что касается полезной нагрузки - это зависит от разработчика (имена объектов в JSON и т. Д.), Но я бы сказал, что в целом JSON также (незначительно) меньше. Включите сжатие на вашем сервере (например, mod_deflate в Apache HTTP ), чтобы сжать биты еще больше;)