Зачастую есть необходимость быстро и непрерывно получать/обмениваться данными с сервером. Зачастую, для такого типа задач используют вебсокеты. Но если ваша задача ограничена только получением данных с сервера без обратной связи, то есть хорошая, незаслуженно забытая, альтернатива - Server-Sent Events. Про разницу, плюсы/минусы можно почитать тут:
➡️ https://blog.bitsrc.io/websockets-vs-server-sent-events-968659ab0870
От себя:
Вообще, задался вопросом про удобство SSE после прочтения лонгрида (тыц) о разработке дизайна системы для «живых комментариев» (aka комментарии к Live-трансляциям). Дизайн применим к любому высоконагруженному сервису с живым комментированием такие как YouTube, Twitch, Facebook, и т.д. В статье довольно подробно описано почему выбран именно SSE, а не другие альтернативы (про них тоже рассказано). Пересказать всё сложно, лучше прочитать самому. Но в голове нужно держать мысль, что не только вебсокетами едины и есть альтернативы.
Из личного опыта проблем с вебсокетами могу отметить две:
1. Скейлинг вебсокет-серверов
А точнее его отсутствие из коробки Если не хочется тянуть сторонние библиотеки, то решить проблему получится только написав свою 🙃 Со сторонними библиотеками скейлинг настроить можно (например, у socket.io за это отвечает адаптер), но это требует лишних усилий как разработчика, так и девопса. К слову, в свое время socket.io mongodb adapter работал некорректно и в итоге пришлось написать свой
2. Несовместимость с proxy-серверами
Зачастую прокси-сервера просто не поддерживают вебсокеты из-за их технической природы (вебсокеты идут поверх TCP, что усложняет поддержку для прокси-серверов). Поэтому, опять приходится прибегать к сторонним решениям с поддержкой long-polling, как у вышеупомянутого socket.io (тыц)
Поэтому, стоит лишний раз обдумать стоит ли ваша задача настройки и поддержки вебсокетов либо ее можно закрыть проще с помощью того же SSE. К слову, для nestjs поднимается просто, например тыц