Комментарии 27
Поищите библиотеки на основе WebSocket для вашего любимого фреймворка и попробуйте использовать новый способ проектирования архитектуры вашего приложения.
Мне показалось, что автор оригинальной статьи призывает меня прогуляться по минному полю вместо него. Причём без карты и в темноте.
хранение состояние на сервере
Где-то в мире стало грустно Рою Филдингу.
Я еще никогда не работал в бизнесе, где стоимость технической инфраструктуры была больше зарплатного фонда.
А между тем, подобных бизнесов — хоть отбавляй.
Мы вот прочитали в своё время интересную статью: https://itnext.io/dont-clone-back-end-models-in-angular-f7a749bdc1b0?_branch_match_id=944819319830954927&gi=2768c1cf7a34
Теперь мы параллельно делаем серверное приложение с API и фронтовое с моками, а потом пишем адаптеры для преобразования и ни у кого не возникает сложностей со структурами=)
У меня тоже есть глубоко личное IMHO, что сервер - "более лучшее" место для хранения стэйта, чем браузер, потому что так разработка веб-приложения становится похожей на разработку десктопного приложения, и уходит целый класс проблем, связанный с асинхронностью, с определением, где должен быть single source of truth и т. п. Но развитие технологий пришло в ту точку, где мы находимся сейчас, и, собственно, повсеместно используются REST, Redux (и аналоги), и синхронизация стэйта между фронтом и бэком каждый раз является проблемой, о которой надо думать и которую надо решать.
Как-то я думал, как бы я решал эту проблему, "была б моя воля". Решения, основанные на том, что на бэке используется фреймворк, поддерживающий континуации (как умеет Seaside), сейчас, наверное, уже будут считаться устаревшими, потому что они вряд ли позволят достичь нужной отзывчивости. Поэтому остаются, да, вебсокеты.
В качестве proof of concept я даже сделал маленький проект на Angular (там есть вроде неплохая библиотека ng-stomp для вебсокетов) и бэком на Spring (и AspectJ). Смысл был такой: проверить, насколько жизнеспособно решение, когда на бэке мы вызываем какой-то сеттер, потом листенер, навешанный на него с помощью аспекта, автоматически отправляет новое значение поля через вебсокет в браузер, а там оно точно так же автоматически отображается на соответствующее место веб-страницы (через установку textContent, для пущей производительности). В принципе, прототип заработал нормально, но нагрузочное тестирование я не делал (не дошло до этого). А интересно было бы посмотреть, юзабелен был бы какой-нибудь дашборд с биржевыми котировками реального времени (и где были бы тормоза).
Да всё просто коллега. Берете ноут 5-6 летней и запускаете.
Я матом обкладываю разработчиков, которые написали Web для пары крупных банков, на react. Да, на современном компе с 16Гб, как-то работает, а вот на таком ноуте одни мучения. И это если не глянуть консоль, куда куча инфы зачем-то попадает. И эти поделия в прод выпустили.
Может проблема не в react и ноуте, а в разработчиках?
Конечно в них. Их же матом обкладываю ;) Библиотеки и фреймворки очень сильно понижают порог входа и расхолаживают. + мало кто реально оптимизирует скрипты. Да пофиг что в цикле к бд запросы, да пофиг масиив будем перебирать в лоб, да пофиг ... моного чего ещё.
Ну то есть по сути, от SPA мы не избавляемся, а просто заставляем страдать сервер за всех, вместо устройств пользователей. Отличное решение, вместо плохого SPA у нас теперь будут еще и затраты на мощный сервер что бы все это крутить. Может дело не в SPA а в том что в него пытаются запихать функционала на приличных размеров декстопное приложение, но выполнять это все на JS.
https://habr.com/ru/post/452480/comments/#comment_20174680 - по этой же теме только чуть более подробно с историей вопроса.
Phoenix LiveView использует чуть хитрее механизм обновления html, в отличии от предшественников они не шлют prepend/append, addClass/removeClass и другие команды для обновления html на стороне клиента, а просто на стороне сервера высчитывают diff и потом его применяют на стороне клиента с помощью morph-dom.
Да и в плане структуризации кода сейчас все продвинулось намного дальше, в Phoenix LiveView можно использовать компоненты. Причем сейчас активно развивается библиотека компонентов Surface UI.
Мысль вообще интересная. Особенно для старичков, кто любит и жалует "старый добрый" подход SSR.
Как интересно наблюдать за тем как Web разработчики открывают для себя транспортные протоколы и идеологии толстых и тонких клиентов спустя десятки лет после их создания...
узнал websocket и стал использовать в момент его появления - и удивляюсь, почему его ещё так надо рекламировать? надо просто использовать и наслаждаться простотой и возможностями, которые он предоставляет для web.
Автор статьи о .Net Blazor вообще ничего не слышал)
Зачем, если есть HTTP3 (QUIC, по сути HTTP2 по UDP)
Он вообще через udp работает, используя его преимущества, и компенсируя недостатки.
Можно даже на будущее казать какие страницы понадобятся и их давать. Да и я слышал, что вебсокеты не нужно из-за HTTP2: https://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete
Вам не нужны веб сокеты, им нужен постоянный коннект.
HTTP со времен 1.1 по дефолту использует постоянный коннект. HTTP/2.0 игнорирует заголовок Connection. Браузеры максимально держат соединение до сервиса.
Ну и неожиданно websocket это обычный tcp. Так что технически нет разнице в транспорте для http и ws.
У http было одно преимущество перед ws - это реализация на его уровне досылки HTTP сообщений при переустановлении соединения. Чистый ws это просто транспорт и в нем нет этого из коробки. Но во всяких прикладных настройках типа socket.io это уже давно реализовано.
Просто отмечу, что будущее давно наступило :)
https://fusion-samples.servicetitan.com/ - режим Blazor Server там делает все, о чем пишет автор. Режим Blazor WASM делает пререндеринг на сервере, а все остальное - на клиенте.
Более того, все это обновляется в real-time, и все это делает один и тот же код, в котором вы не увидите практически ничего про real-time - там нет событий и т.п., но обновляется только то, что нужно.
Демка сделана с:
Disclaimer: я - автор Fusion.
Мне нравится этот подход, но тогда придется отказаться от progressive applications ибо для них нужна будет отдельная разработка -> ресурсы. Ибо без интернета это все дело не будет работать. А до достаточно быстрого старлинка или его аналогов ещё долго.
Сокеты рулят, однозначно!
Но руби... Ты серьезно ? ))))
Будущее Web это HTML через WebSockets