Пожалуйста. uWebsockets

Сверхбыстрый веб стек на js

1 стратегия штанги - в смысле не стоит инвестировать в хайп?
2 практика надежней теории - в смысле начни делать что то, чем долго искать идеальный стек?
3 via negativa(через отрицание) - сложный и крутой стек не обязательно поможет моему проекту именно из за свое сложности?

Что именно вы имеете в виду? какой именно вопрос?)

вот эти?
https://github.com/uNetworking/uWebSockets

Да

Не совсем понятно как на этой технологии создать сайт. Это скорее для общения твоего фронтенда с бекендом, или я что не правильно понял?

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

Несмотря на название это и http сервер тоже

Сверхбыстрый

Ладно, возвращаясь к вопросу,
Можно ли рассматривать в качестве кандидатов angular universal.
на сколько я понял, бандл стал необычайно маленький, с выходом 9ой версии. может быть можно стартовать на нем проект для котрого критически важно SSR, тогда и uWebsockets можно будет заюзать.

Просто если не Rest или вот эти ваши сокеты, тогды мы приходим к сессиям, а в таком случае, мы действительно ничего не выигрываем от ноды

или я что то не правильно понял?

На мой взгляд вебсокеты нужны всем, даже сайтам по типу блога. Как только на сайте есть динамические данные (которые могут меняться) сразу появляется проблема их актуализации. С server-side рендером юзер не увидет новые данные пока вручную не обновит страницу. С  spa дело уже лучше но с текущими технологиями но тут зоопарк подходов и решений. Многие делают запросы при маунте компонентов а это значит юзеру нужно переключаться по внутренним экранам сайта чтобы получить новые обновления данных. С новыми подходами вроде suspence ситуация еще больше усложняется и вообще непонятно почему такое смещение у сообщества в сторону получения данных (и кеширования) вместо реалтайм оповещений (популярность всяких fetch, axios и т.д даже у graphql загрузка данных и получение оповещений по данным это совсем разные подходы/запросы/техники)
Я вот вообще не вижу разницы между запросом за данными и реалтайм-оповещениями. Для меня загрузка данных это просто initial-реалтайм-оповещение которое будет включать в себя данные которые необходимы для отображение экрана сайта или его части.
И вместо того чтобы юзать всякие axios-ы или любые библиотеки для http я сделал всю коммуникацию с сервером через вебсокеты - не только получение оповещений но и начальная загрузка необходимых данных. И все стало проще. Никакого http, никакой возни со статусами ошибок и дилемм как передавать данные и какие моменты http юзать (POST vs PUT, path vs query vs headers vs body). Просто настроили единственный коннект по вебсокетам (которые автоматически переподключается при обрыве связи) и дальше просто получаем нужные обновления данных (ну и заодно отсылаем запросы на их изменения)

До тех пор пока не встречаем реалии к примеру американской копюрпоративной среды

Где вебсокеты не работают

Или что нормально приземлять вебсокеты в облако пока никто не умеет (у Амазона с этим получше но тоже есть вопросы)

почему не работает? у них что файлволл стоит или есть всякие полиси которые запрещают вебсокеты?

У них стоят ископаемые прокси которые не умеют в вебсокеты

ну кстати да, еще раз говорит о том что хайп на облака преувеличен, хорошо что на своем vps сервере можно делать все что угодно. Хотя кстати облака ведь должны юзать один и тот же коннект для работы keep-alive а это технически практически не отличается от вебсокетов

Облака это точно не хайп. Они решают очень много проблем :)