Блог

Мой проект представляет собой приложение с полным стеком, в котором веб-клиент подписывается на неготовый объект. Когда подписка запускается, серверная часть запускает цикл наблюдения для этого неготового объекта, пока он не станет готовым. Когда это происходит, он отправляет сообщение интерфейсу через SocketIO (предложения приветствуются, я не совсем уверен, что это лучший метод). Мой вопрос в том, как мне построить цикл наблюдения.

Мой интерфейс в основном подписывается на серверную часть и получает возврат 200 и подключается к серверу для каждого веб-сокета (SocketIO), если он был подписан правильно, или код ошибки 4XX, если что-то пошло не так. На серверной части, когда пользователь подписывается, для этого пользователя должен запускаться «поток» (я знаю, что Nodejs не поддерживает потоки, это просто для мысленного образа), который опрашивает информацию из API каждые 10 или около того секунд.

Я делаю это, потому что API, из которого я опрашиваю, не поддерживает WebHooks, поэтому мне нужно наблюдать за ответом API, пока он не будет в том состоянии, в котором я хочу (эта часть я уже очистил).

Я спрашиваю, есть ли сторонняя библиотека, которая на самом деле предназначена для таких задач? Должен ли я использовать рабочие потоки или простые setTimeouts, абстрагированные классами? Ответ будет отправлен через SocketIO, эта часть, которую я уже получил, также работает, это просто метод, который я использую, я не совсем уверен, как построить.

Я также открыт для использования другого подходящего языка программирования, который упрощает решение этого случая. Я не спешу.

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

Итак, один поток nodejs может выполнять множество сетевых запросов (для вашего опроса и для отправки данных через сокет.подключение к io) без добавления рабочих потоков или кластеризации. Это то, в чем nodejs очень, очень хорош.

Я не знаю ни о какой сторонней библиотеке специально для этого, поскольку вам все равно приходится настраивать код, просматривая результаты сетевого запроса, и это большая часть кода. Существует множество библиотек для выполнения http-запросов других серверов из nodejs, перечисленных здесь. Мой любимый в этом списке — got() , но вы можете посмотреть варианты и решить, что вам нравится.

Что касается повторных запросов, я бы, вероятно, просто использовал либо повторные setTimeout() вызовы, либо setInterval() вызов.

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

Если при масштабировании возникают проблемы с масштабированием, вы можете переместить код опроса в один или несколько дочерних процессов или рабочих потоков, а затем просто связаться с основным потоком посредством обмена сообщениями, когда вы нашли новое состояние, которое необходимо отправить клиенту. Но я бы не ожидал, что вам потребуется кодировать этот дополнительный шаг, пока вы не достигнете большего масштаба. Как и в большинстве случаев масштабирования, вам нужно будет закодировать более простой вариант (который должен хорошо масштабироваться сам по себе), а затем измерить и сравнить, посмотреть, где есть узкие места, и изменить архитектуру на основе данных, а не предположений. Слишком часто архитектура чрезмерно продумана и чрезмерно реализована на основе того, где, по мнению людей, могут быть узкие места, а не там, где они на самом деле оказываются. Это не только увеличивает время разработки и приводит к более сложной реализации, чем требуется, но и может нацелить разработку на неправильную часть проблемы. Профилируйте, измеряйте, затем решайте.