GWT-RPC по сравнению с HTTP-ВЫЗОВОМ - который лучше?
Я оцениваю, если существует изменение производительности между вызовами, выполненными с помощью GWT-RPC и HTTP-ВЫЗОВА.
Мои appln сервисы размещаются как сервлеты Java, и я в настоящее время использую соединения HTTPProxy для выборки данных от них. Я надеюсь преобразовывать их в GWT-вызовы-RPC, если это вводит повышение производительности.
Я хотел бы знать о профессионалах/недостатках каждого...
Также любые предложения на инструментах для измерения уровня Асинхронных вызовов...
[Хорошая статья о различных коммуникационных стратегиях Сервера, которые могут использоваться с GWT.]
4 ответа
Я написал статью, упомянутую в вопросе (спасибо за ссылку!).
Как всегда, ответ "зависит от ситуации". Я использовал и GWT-RPC, и JSON.
Как было сказано выше, GWT-RPC позволяет добиться серьезной производительности при передаче java-объектов (с некоторыми ограничениями) по проводам. Некоторая логика может быть общей, а GWT позаботится о маршалинге/немаршалинге вашего объекта.
JSON позволяет осуществлять междоменный доступ и потребление другими, не GWT-клиентами. Вы можете обойтись оверлейными типами, но никакое поведение (например, валидация) не может быть общим. JSON также можно легко сжимать и кэшировать, в отличие от GWT-RPC (в последний раз, когда я смотрел).
Поскольку мы не знаем, что представляет собой полезная нагрузка, рекомендации по производительности дать сложно. Я бы рекомендовал (опять же, как кто-то сделал выше) протестировать себя.
В целом я согласен с Джейсоном - если на вашей стороне сервера используется Java, используйте GWT-RPC. Вы сможете повторно использовать POJO, логику проверки и т. Д. RPC также имеет тенденцию «играть» лучше с MVP и разделением кода.
Однако, если на вашей стороне сервера используется что-то еще, используйте JSON - но не волнуйтесь, с типами наложения JavaScript с использованием JSON совсем несложно. Однако вы не сможете повторно использовать код со стороны клиента на сервере (YMMV).
С точки зрения производительности - я бы сказал, что здесь преимущество JSON. В современных браузерах есть несколько действительно хороших методов быстрого кодирования / декодирования JSON. Я не уверен, что такое GWT-RPC «за кулисами», но сомневаюсь, что он может превзойти JSON, когда дело касается скорости. Что касается полезной нагрузки - это зависит от разработчика (имена объектов в JSON и т. Д.), Но я бы сказал, что в целом JSON также (незначительно) меньше. Включите сжатие на своем сервере (например, mod_deflate в Apache HTTP ), чтобы сжать биты еще больше;)
GWT-RPC обычно предпочтительнее, когда бэкэнд также написан на Java, поскольку это означает отсутствие необходимости кодировать и декодировать объект на каждом конце - вы можете просто передать обычный объект Java клиенту и использовать его там.
JSON (с использованием RequestBuilder) обычно используется, когда бэкенд написан на каком-то другом языке, и требует от сервера JSON-кодирования объекта ответа, а от клиента JSON-декодирования его в JavaScriptObject для использования в коде GWT.
Если бы мне пришлось гадать, я бы сказал, что GWT-RPC также приводит к меньшим транспортным объектам, потому что команда GWT оптимизирует их для этого случая, но любой из этих вариантов будет работать, и JSON все равно может быть довольно маленьким. В большинстве случаев это просто сводится к вопросу удобства разработчика.
Что касается инструментов для измерения времени запроса, вы можете использовать либо инструменты разработчика Chrome/Webkit, либо расширение Firebug для Firefox, либо измерять время запроса в вашем приложении и отправлять данные метрики обратно на сервер в отложенном запросе для сбора и анализа.
Просто дополнение к другим ответам, есть один момент, который следует учитывать, который может повлиять на ваше решение в отношении JSON, даже если вы используете Java на серверной стороне:
Может быть, когда-нибудь в в будущем вы хотите, чтобы клиенты, не использующие GWT, могли общаться с вашим сервером. Многие современные сайты предлагают какой-то доступ к API, и если вы используете JSON, у вас в основном уже есть сравнительно открытый API.