Ajax vs Socket.io - программирование

Я разрабатываю веб-приложение, и мне было интересно, какой метод должен быть подходящим для моего проекта.

В основном, что я хочу отображать для пользователей, есть некоторые уведомления, которые берутся из запросов на другие серверы. Мое приложение node.js получает всю информацию, а затем распространяется на пользователей, сохраняя копию в моем MongoDB.

Идея довольно проста, но, читая о методах, я нашел эти два метода:

Ajax: клиентская сторона будет проверять все время, если на сервере будет новый контент. Это будет сделано с использованием jquery ajax для моего API-интерфейса (каждые 30/60 секунд).
Socket.io: клиент подключается один раз, а затем поддерживается постоянное TCP-соединение (больше в реальном времени).

Теперь я объяснил ситуацию, у меня есть следующие вопросы:

Не было бы у меня слишком много запросов с ajax? представьте, что я хочу каждую минуту проверять сервер, если мы масштабируем приложение до 100 пользователей, оно даст мне 100 запросов в минуту. Было бы "дешевле" в системных ресурсах иметь сокет?
Будет ли проблема сокета socket.io для мобильных устройств? полоса пропускания и производительность. Ответ сервера всегда является информацией в формате JSON.
Я читал, что now.js можно использовать для этого, но кажется, что проект больше не поддерживается, поэтому не уверен, что использование его было бы хорошей идеей.
Как кэширование обоих методов? Я рассматривал возможность создания файла кэша для каждого пользователя, и он будет обновляться с помощью node.js на стороне сервера. Я думаю, это может отлично работать с ajax, но как насчет socket.io?
Правда ли, что socket.io не совместим со многими браузерами? Мое приложение будет более сфокусировано на мобильных устройствах, и я думаю, что это может заставить меня подумать о выборе ajax.
Предлагается любая альтернатива?

Надеюсь, это может очистить мой разум и других, которые находятся в одной и той же ситуации:) Благодаря

Ответ 1

Многие из общих компромиссов между webSocket и Ajax обсуждаются здесь:

websocket vs rest API для данных в реальном времени?

Некоторые проблемы компромиссов для мобильных устройств обсуждаются здесь:

Кордова: Сокеты, PushNotifications или многократно опросный сервер?

В двух словах, если ваши данные в основном управляются сервером и затем должны быть отправлены клиентам, и вы хотите достаточно хорошую задержку, когда клиенты видят новые данные, то это точная проблема, с которой веб-сокеты хороши для, webSockets работают лучше всего в этой ситуации, потому что клиенту не нужно часто опроса, сервер не должен обрабатывать регулярные запросы опроса от множества клиентов. Вместо этого каждый клиент просто устанавливает один постоянный канал связи WebSocket, который сервер может затем отправлять данные по запросу в любое время.

Не было бы у меня слишком много запросов с ajax? представьте, я хочу проверить каждую минуту на сервер, если мы масштабируем приложение до 100 пользователей, это будет дайте мне 100 запросов в минуту. Было бы "дешевле" в системе ресурсов, чтобы иметь сокет?

Сокеты требуют очень мало ресурсов, когда они неактивны, так что да, постоянный webSocket более эффективен, чем много опросов клиентов бесконечно. Вот почему webSockets были изобретены, потому что они лучше справляются с этой конкретной проблемой.

Будет ли socket.io проблемой для мобильных устройств? полосы и представление. Ответ сервера всегда является информацией в формате JSON.

socket.io не является проблемой для полосы пропускания или производительности. Есть некоторые проблемы с мобильностью при попытке использования web-сокетов в фоновом режиме, поскольку мобильные устройства также пытаются активировать управление питанием, хотя подобная проблема возникает и при опросе клиентов.

Как кэширование обоих методов? Я собирался создать кэш файл для каждого пользователя, и это будет обновляться с помощью node.js в на стороне сервера. Я думаю, это может отлично работать с ajax, но как насчет socket.io?

Непонятно, что вы спрашиваете о кешировании? В реализации webSocket сервер получает данные, а затем просто отправляет их каждому пользователю. В общем случае кэширование на стороне сервера не требуется. В реализации запроса клиента Ajax сервер должен будет хранить данные где-то и "ждать" для каждого клиента, чтобы затем запросить данные. Нет никакого "встроенного" механизма кэширования для websocket или Ajax.

Правда ли, что socket.io несовместим вообще со многими браузерами? Мое приложение будет больше ориентировано на мобильные устройства, и я думаю, что это может заставить меня задуматься о выборе ajax.

socket.io полностью совместим со всеми браузерами, у которых есть веб-узлы, которые в значительной степени используются сегодня, кроме IE9 и старше. Если вы используете библиотеку socket.io, она автоматически возвращается к длительному опросу, если веб-сокеты не существуют. Вероятно, ваши проблемы с мобильностью будут одинаковыми, независимо от того, выполняете ли вы обычный опрос или веб-узел, потому что мобильное устройство хочет управлять долговременными вещами, но вы не хотите прекращать опрос. Я не думаю, что это причина для того, чтобы избежать использования webSockets/socket.io. socket.io имеет некоторую действительно приятную логику автоматического повторного подключения, когда он теряет соединение, которое может быть действительно полезным.

В мобильном мире, я думаю, вы просто обнаружите, что не можете надежно делать уведомления в режиме реального времени в фоновом режиме, не используя какой-то родной компонент приложения, который может подключаться к собственной "push" системе на потому что это единственная система, которая одновременно эффективна и полностью совместима с управлением питанием. Веб-страница будет управляться электропитанием, как только это не будет задачей переднего плана или когда устройство не работает.