Как стать автором
Обновить

Комментарии 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 разработчики открывают для себя транспортные протоколы и идеологии толстых и тонких клиентов спустя десятки лет после их создания...

Пришло совсем новое поколение "разработчиков", которые даже чаты делают на HTML и HTTP, понимаете...

узнал 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 ибо для них нужна будет отдельная разработка -> ресурсы. Ибо без интернета это все дело не будет работать. А до достаточно быстрого старлинка или его аналогов ещё долго.

А оно и сейчас без интернета ничего не работает. Тыкнешь на ссылку- белый экран на тлф висим ждём коннекта. Тут главное терпение, потому что если ещё протыкать, то когда отвиснет улетишь неизвестно куда, концов не найдёшь.
Инстаграм кстати пишет '«Вы в режиме оффлайн. Ваши лайки будут добавлены после соединения». То есть приложение не кидается по клику перерисовывать экран, а сначала проверяет коннект

Сокеты рулят, однозначно!

Но руби... Ты серьезно ? ))))

А что не так с руби?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории