Проект Hotwire, реализующий HTML по WebSocket
Проект Hotwire, реализующий HTML по WebSocket

Будущее веб архитектуры  программного обеспечения уже обретает формы и на этот раз это server-side рендеринг(опять). Но есть кое-что новенькое,  а именно передача HTML по WebSocket.

Подход с использованием SPA(Single Page Appllication) и JSON API привел к тому, что многие команды разработки погрязли в бесконечных спорах о структуре данных и ошибках синхронизации между этими двумя слоями. Это увеличивает стоимость разработки, замедляет релизный цикл и сокращает время, которое можно было бы потратить на инновации.

Внимание web разработчиков привлекает новый WebSocket ориентированный подход. Данный подход имеет такие же плюсы, что и классические серверные фреймворки: быстрое прототипирование, хранение состояния на сервере, быстрая отрисовка страницы, быстрое добавление функций и простая поддержка SEO. При этом он обеспечивает многопользовательскую работу и отзывчивый интерфейс без создания двух отдельных приложений. Конечным результатом является единственный репозиторий, но при этом пользователи наслаждаются такой же отзывчивостью будто это полностью JavaScript приложение. При этом у нас более простая шаблонизация, меньше прелодеров с надписью «Загрузка…» и нет ошибок хранения состояния ведь оно живет в одном месте. Все это приводит нас на путь более простой (и быстрой) разработки софта.

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

И по моему мнению, нет лучше фреймворка для уменьшения количества рутины, чем Ruby on Rails. Взгляните еще раз на недооценённый Stimulus JS. Улучшите View в своем MVC с помощью ViewComponents. Добавьте библиотеки CableReady and StimulusReflex для получения реактивного Rails и ваш старый добрый авто снова готов к гонкам. Но мы позже вернемся к Rails…

Все началось с web фреймворков…

Бэкенд фреймворки для  web появились примерно в 2005 году посреди моря самописных скриптов, объединяющих набор библиотек, которые запускались под Apache сервер. Представленная новая архитектура обещала разработчикам более целостный подход. Девизом этого подхода был  «Соглашение над конфигурацией». Фреймворк решал за разработчика многие спорные моменты и давал ему возможность сосредоточиться на создании  читабельного кода и быстрой разработке фич. Все что нужно было разработчику это изучить ядро фреймворка и его соглашения, а затем можно было начать создавать сложные web приложения, пока его коллеги продолжали писать конфигурационные XML файлы для всех других подходов разработки.

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

Но потом JavaScript захватил мир…

К 2010 году тенденции стали меняться и server-side фреймворки отошли на второй план из-за появления Single Page Application полностью разрабатываемого на JavaScript и работающего в браузере пользователя. Во многих компаниях, часть сервера была низведена до уровня раздачи данных по API, а большая часть бизнес-логики и весь HTML рендеринг происходил на клиенте. Из-за этого пользователям приходилось грузить большой бандл с JS кодом при первом посещении сайта.

Вот тогда-то все и стало ужасно.

Перенесемся обратно в 2020, где web не стал быстрее как нам обещали с SPA. Засовывание мегабайт JavaScript кода в глотку Iphone 4’s не улучшает пользовательский опыт. И если вы думали, что создание профессионального web приложения требует серьезных ресурсов, то что вы думаете про создание web приложения, api для него и прослойки коммуникации между ними? Мы действительно верим в том, что каждый наш пользователь будет иметь устройство способное переварить 100 Kb JSON и отрендерить сложную HTML таблицу быстрее чем серверное приложение на средненьком сервачке?

Разработка и раздача SPA тоже не стали дешевле. Во многих случаях мы теперь должны делать двойную работу(и возможно платить двум разработчикам) для получения точно такого же результата, что и с server-side фреймворками.

В 2005 году фреймворки взорвали умы всех  с помощью видеороликов «Как создать блог-сайт за 15 минут». Пятнадцать лет спустя, делая тоже самое с помощью SPA нам нужно две кодовые базы, слой JSON сериализации и повсюду десятки прелодеров, чтобы мы могли еще заявлять о 50мс загрузке страницы с контентом. В это же время пользователь наблюдает за несколькими серыми прямоугольниками, надеясь что HTML наконец-то отрисуется из JSON, который  запрашивает и обрабатывает его браузер.

Как мы сюда попали? Это не то светлое будущее, которое я хотел. Стоило ли от отказаться от сервер сайд "счастья" и удваивать штат сотрудников, а так же время для реализации, чтобы обеспечить нашим пользователям более прикольный UI?

Ну, как бы да.

Мы не создаем web приложения для себя. Мы их создаем его для пользователей. У пользователей нашего софта  есть ожидания о том, как оно будет работать. Мы должны оправдать ожидания пользователей. Наши пользователи больше не восторге от полностраничных обновлений и “простыни” из множества форм вложенных  друг в друга.

SPA был следующим этапом от кучи разнородных js файлов, живущих на сервере. Проблема в том, что это лучше на 5%, а не 500%.

Стоит ли 5% улучшение двойной работы? Что насчет стоимости разработки?

Впечатляющие web приложения создают более прикольный UX с точки зрения пользователя. Хорошо сделанное приложение может быть более бесшовным и интерактивным, что дает возможность для новых способов взаимодействия. Оформление элементов интерфейса как компоненты было следующим этапом эволюции. Прошли те дни, когда мы думали о том, как мутировать страницу HTML, чтобы создать иллюзию взаимодействия пользователя с виджетом на странице. Теперь мы думаем о нашем UX с точки зрения компонентов и изменяем непосредственно их. Но, увы, расходы почти сразу начинают расти.

Давайте напишем маленький блестящий компонент рейтинга (звездочки). Добавим несколько клевых анимаций, чтобы область наведения мышки и щелчок курсором давали нам интерактивную обратную связь, сопровождающуюся приятной анимацией. Но что теперь? В реальном приложении, нам надо сохранить изменение, верно? База данных должна быть изменена, отразив новое состояния, и приложение перед глазами пользователя тоже должно отразить новую реальность.

Раньше мы отдали бы пользователю несколько GIF’s, каждая из которых была бы ссылкой на один и тот же url c разными параметрами. На сервере мы бы сохранили изменение в БД, а затем отправили новую HTML страницу на перерисовку в браузер. Возможно, мы бы придумали более приятный способ с помощью AJAX, избавившись от перерисовки страницы. Предположим, что x это деньги и время потраченные на разработку (и мы не говорим о потерях, связанных со слишком долгим циклом разработки функционала). В данном случае более интерактивный AJAX подход будет стоить  x+n (нам же придется писать дополнительный JS код), но n будет все больше и больше расти по мере того как мы будем добавлять то там, то здесь JS код.

В мире SPA мы пишем JavaScript код на клиентской стороне, используя JSX, Handlebars или другие шаблонизаторы для отрисовки компонентов, а затем пишем код для изменения состояния в нашем приложении (на клиенте) после чего инициализируем http запрос через API  для изменения данных на сервере. Кроме того, надо написать API обработчик для этого запроса на сервере, а также обеспечить сериализацию JSON как на сервере, так и в нашем приложении. И наконец,  наш код должен обеспечить перерисовку компонента в случае успешного ответа с сервера (и при этом возможна отдельная логика, связанная с отменой изменений и перерисовкой, если backend вернул нам ошибку). Эти затраты гораздо больше, чем x+n, о которых мы говорили выше. И если вы разделили свою команду на фронтэнд и бэкенд, то скорее всего вы удвоите стоимость (деньги и время) для реализации множества нетривиальных компонентов, где необходимо хотя бы по одному участнику от каждой стороны. Разумеется SPA сглаживает проблему растущего спагетти кода, но какой ценой для бизнеса, а именно time to market и себестоимость проекта начинают стремительно расти.

Другой аргумент, который мы слышим в поддержку SPA, это сокращение стоимости содержания инфраструктуры. Как будто перекладывание этого бремени на клиента (без его согласия в большинстве случаев, но это уже другая тема) каким-то образом уменьшит наши счета за облачные услуги. Это же смешно. Для любого нетривиального приложения вы все-равно платите за хостинг API и возможно еще и за базу данных, не о говоря уже о балансировщике, DNS и т.д. И вот что, ни одна из этих затрат не сравнится с тем, сколько софтверные компании платят разработчикам. Серьезно, подумайте об этом. Я еще никогда не работал в бизнесе, где стоимость технической инфраструктуры была больше зарплатного фонда. И при этом хорошие разработчики ожидают ее повышение, а облака напротив в основном дешевеют с течением времени.

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

Давным-давно до появления web фреймворков, вы бы заплатили разработчику за шесть недель работы, чтобы он только начал прототипировать страницу авторизации. Звучит ужасно! С фреймворками создание страницы авторизации занимало час, а за ночь некоторые запускали стартап. Звучит превосходно! Теперь же с SPA подходом мы опять имеем кучу дополнительной работы. Это стоит больше денег, потому что мы должны писать две кодовые базы одновременно. Звучит не очень круто…

Мы платим очень много денег за улучшение пользовательского опыта на 5%.

Но что если мы могли бы взять лучшие идеи SPA и подходы JavaScript библиотек, которые обеспечивают улучшение использования на 5%, и переосмыслить их с учетом удобства разработки и экономии на заработной плате, используя одну кодовую базу? Что если бы компоненты находились бы в одном монолитном приложении, оптимизированном для сервер сайд рендеринга? Возможно это способ улучшения на 500%?

Это кажется невозможным? Но это не так. Я создал такое приложение в свободное время, когда мои дети бегали вокруг меня, лая как собаки. Приложение использует обновление по WebSocket для зарегистрированных пользователей и мгновенно обновляет DOM на клиентской стороне за миллисекунды. При этом используется 3D анимация на JavaScript для отрисовки окон реал-тайм чата. И все это в одной кодовой базе, на том же самом серверном оборудовании, которое я бы использовал для классического  сервер-сайд рендеринга (и возможно я даже могу замасштабироваться на этом оборудовании, так как я чаще отрисовываю кусочки HTML, а не всю страницу целиком). И мы избавились от отдельного фронтэнд приложения. Чистый, компонентный JavaScript и серверный код сочетаются так же хорошо как хлеб с маслом. И это возможно!

Сокета мне! (Поняли? Поняли? Ладно, не важно…)

Наконец в 2011 году, WebSocket получил полную поддержку во всех современных браузерах. С помощью небольшого количества JavaScript кода, мы получаем мультидуплексное соединение между браузером и сервером. Данные могут передаваться в обе стороны и могут быть отправлены с любой стороны в любой момент, не требуя действий со стороны пользователя.

Подобно игровой индустрии, которая развивается в сторону облачного гейминга, будущее web приложений не в том, чтобы взваливать еще больше работы на клиентское устройство, напротив: пусть браузер будет тонким клиентом, который просто отрисовывает то или иное состояние для пользователя. WebSocket обеспечивает транспортный уровень, бесшовный и быстрый, напрямую к пользователю.

Поначалу многим разработчикам было довольно непросто осознать новый подход. Мне тоже. И выгода была не очевидна. Использование другого технологического транспорта, как WebSocket, вызывает недоумение после нескольких лет (даже десятилетий) выстраивания логики работы вокруг отправки и получения HTTP запросов. Как и в случае с большинством новых технологий или протоколов нам была нужна абстракция более высокого уровня, которая обеспечивала бы быстрое создание функционала для пользователей.

Передача HTML по WebSocket

Хотите супер отзывчивый dropdown с autocomplete(<datalist>), который идеально синхронизирован с БД? На каждое нажатие клавиши отправляется запрос через WebSocket, который возвращает необходимый набор данных ни больше, не меньше.

Как насчет валидации? Все просто. На каждое изменение данных в input, извлеките значение поля и отправьте по WebSoсket. Пусть ваш серверный фреймворк провалидирует и отправит ответ прямо в виде HTML, включая любые ошибки, которые необходимо отрисовать. Нет необходимости в JSON,  в том числе в сложных объектах ошибки.

Индикаторы присутствия пользователя на сайте? Элементарно. Просто проверьте  на сервере у кого активное соединение через socket.

Что насчет многопользовательского чата? Или совместного редактирования документа? В классических фреймворках и SPA мы откладываем эти фичи до последнего из-за их сложности и путаного кода, требующегося для корректной синхронизации состояния у всех клиентов. С HTML по WebSocket, мы просто отправляем небольшие кусочки HTML в зависимости от действий одного пользователя всем другим пользователям, которые сейчас активны. Они увидят те же данные, как если бы они обновляли страницу и получали всю HTML страницу заново с сервера. И вы можете получать эти кусочки данных для каждого пользователя в пределах 30 миллисекунд.

Но при всем при этом мы не отказываемся от компонентов. Подход, основанный на WebSocket можно рассматривать, как «толстый» сервер/«тонкий» клиент, тоже самое можно сказать и про наши компоненты. Это гениально! Заставьте компонент делать восхитительные вещи для пользователя с помощью «умного» JavaScript, а затем просто попросите сервер обновить HTML. Нет необходимости в хранении данных в storage (Redux, Vuex и т.д.) на клиенте, чтобы управлять состоянием компонента, ведь он выглядит в точности так, как ему об этом сообщил сервер. HTML приходит с сервера, следовательно нет необходимости в JSX, Handlebars или любой другой библиотеке для шаблонизации на клиенте. Сервер все держит под контролем, как первоначальную отрисовку компонента, так и его последующее обновление в случае изменений. Все это делается через соединение по сокету.

И никто не говорит, что вы должны использовать сокет только для отправки HTML. Можете отправлять кусочки текста, и пусть клиент сам решит что с этим делать. Например, когда отправляется сообщение от одного пользователя всем остальным участникам чата, и клиентский код каждого может сам решить, как отрисовать сообщение в зависимости от пользовательских настроек/темы. Представьте, какие возможности открываются!

Но это сложно/дорого/требует кучу новой инфраструктуры, не так ли?

Это совсем не так. Наиболее популярные open-source веб-сервера поддерживают WebSocket из коробки без необходимости дополнительной конфигурации и настроек. Многие серверные фреймворки автоматически отправляют JavaScript код  на клиент для удобной работы с вебсокетами. Например, в Rails настроить работу с WebSocket так же просто, как настроить встроенный ActionCable, а затем задеплоить на ту же инфраструктуру, которую вы бы использовали для обычного приложения. Надо отметить, что обычное Rails приложение совершенно спокойно справляется почти с 4 000 активных соединений. И вы можете абсолютно спокойно увеличить это число  до 10 000+ соединений, используя AnyCable вместо встроенного Ruby WebSocket сервера. Опять же используя для этого стандартное оборудование, которое вы бы использовали для запуска обычного web сервера. Вам не нужно настраивать дополнительное оборудование или увеличивать свою облачную инфраструктуру.

Этот новый подход появляется в виде расширений, библиотек или альтернативных конфигураций в различных языках и web фреймворках: Sockpuppet(Django), Phoenix LiveView(Elixir), Korolev(Scala), ts-liveview(NodeJS), Hotwire(Ruby), Vaadin(Java). Поищите библиотеки на основе WebSocket для вашего любимого фреймворка и попробуйте использовать новый способ проектирования архитектуры вашего приложения. Постройте что-нибудь удивительное и восхищайтесь великолепными кусочками HTML, проносящимися по сокетам подобно реактивному истребителю по ночному небу. Это больше, чем новый технический подход, это новый способ мышления и, возможно, даже источник новых фич, которые принесут вашему стартапу успех.

Но я бы не был собой, если бы не упомянул лучшего претендента на эту роль для читателя. Разумеется, любой фреймворк может реализовать этот подход, но мне кажется, лучше всего на эту роль подходит Ruby on Rails.

Итак, мы возвращаемся к Rails, спустя 15 лет после его появления…

Настройте Rails 6 с последней версией  Turbolinks, Stimulus, StimulusReflex, CableReady and gems Github ViewCompinent, и вы сможете работать с реактивным Rails будто создаете классическое Rails приложение и одновременно современное компонентное SPA приложение, в одной кодовой базе, со всеми преимуществами сервер-сайд рендеринга, кэшированием HTML элементов, простым SEO, надежной безопасностью и всем остальным. Вы внезапно обнаружите, что теперь ваш набор инструментов состоит из множества простых вещей, позволяющих решать задачи, которые раньше были пугающе сложными.

И с помощью Turbolinks вы также получаете обертки, позволяющие использовать нативный гибридный HTML UI в единой кодовой базе. Используйте быстрое решение для деплоя, как Heroky или Hatchbox, и один разработчик сможет создавать  отзывчивое и мультиплатформенное  приложение в свое свободное время. Взгляните на этот клон Twitter, если вы мне не верите.

Ладно, звучит интересно, но почему именно Rails? Разве он не устарел? Ты же сказал, что любой фреймворк даст аналогичные преимущества, если использовать его в связке с  WebSocket и DOM патчинг, не так ли?

Конечно. Но Rails всегда славился тем, что можно делать быстрые прототипы, и системой хорошо написанных gem пакетов. Он не остановился в развитии, Rails 6.1.3 имеет множество интересных фич.

Если у вас маленькая и ограниченная ресурсами команда, Ruby on Rails служит мощным инструментом, позволяющий вам прыгнуть выше своей головы. С новым подходом ваша команда может создать на порядок больше функционала. Пока ваши конкуренты возятся с сериализацией JSON в своем API и борются за уменьшение количества индикаторов загрузки в своем UI, вы запускаете новую многопользовательскую функцию для совместной работы каждую неделю или даже день.

И все в выигрыше: разработчики, бизнес и, что самое главное, ваши пользователи.

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

Евангелист Ruby и автор “The Ruby Way” , Obie Fernandez кажется так же думает.

Черт, даже Russ Hanneman считает, что новый подход с StimulusReflex перспективен.

И классные парни из Basecamp (первоначальные создатели Rails) отказались от своего концепта в пользу Hotwire, чтобы добавило еще один способ для реализации ранее описанного подхода.

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

Реактивный Rails c StimulusReflex и "друзьями" это обязательная вещь для ознакомления для тех, кто устал от работы с JSON API или JSX, и я буду очень рад видеть новое поколение приложений, которые он позволяет создать.

P.S. Использовали ли вы такой подход на перечисленных выше языках/фреймворках и что о нем думаете, напишите свое мнение в комментариях.

Комментарии (27)


  1. flancer
    03.08.2021 12:12
    +3

    Поищите библиотеки на основе WebSocket для вашего любимого фреймворка и попробуйте использовать новый способ проектирования архитектуры вашего приложения.

    Мне показалось, что автор оригинальной статьи призывает меня прогуляться по минному полю вместо него. Причём без карты и в темноте.


  1. Cykooz
    03.08.2021 12:48
    +2

    хранение состояние на сервере

    Где-то в мире стало грустно Рою Филдингу.


  1. boulder
    03.08.2021 12:59
    +1

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

    А между тем, подобных бизнесов — хоть отбавляй.


  1. CLTanuki
    03.08.2021 13:52
    +1

    Мы вот прочитали в своё время интересную статью: https://itnext.io/dont-clone-back-end-models-in-angular-f7a749bdc1b0?_branch_match_id=944819319830954927&gi=2768c1cf7a34

    Теперь мы параллельно делаем серверное приложение с API и фронтовое с моками, а потом пишем адаптеры для преобразования и ни у кого не возникает сложностей со структурами=)


  1. klvov
    03.08.2021 14:04
    +1

    У меня тоже есть глубоко личное IMHO, что сервер - "более лучшее" место для хранения стэйта, чем браузер, потому что так разработка веб-приложения становится похожей на разработку десктопного приложения, и уходит целый класс проблем, связанный с асинхронностью, с определением, где должен быть single source of truth и т. п. Но развитие технологий пришло в ту точку, где мы находимся сейчас, и, собственно, повсеместно используются REST, Redux (и аналоги), и синхронизация стэйта между фронтом и бэком каждый раз является проблемой, о которой надо думать и которую надо решать.

    Как-то я думал, как бы я решал эту проблему, "была б моя воля". Решения, основанные на том, что на бэке используется фреймворк, поддерживающий континуации (как умеет Seaside), сейчас, наверное, уже будут считаться устаревшими, потому что они вряд ли позволят достичь нужной отзывчивости. Поэтому остаются, да, вебсокеты.

    В качестве proof of concept я даже сделал маленький проект на Angular (там есть вроде неплохая библиотека ng-stomp для вебсокетов) и бэком на Spring (и AspectJ). Смысл был такой: проверить, насколько жизнеспособно решение, когда на бэке мы вызываем какой-то сеттер, потом листенер, навешанный на него с помощью аспекта, автоматически отправляет новое значение поля через вебсокет в браузер, а там оно точно так же автоматически отображается на соответствующее место веб-страницы (через установку textContent, для пущей производительности). В принципе, прототип заработал нормально, но нагрузочное тестирование я не делал (не дошло до этого). А интересно было бы посмотреть, юзабелен был бы какой-нибудь дашборд с биржевыми котировками реального времени (и где были бы тормоза).


    1. Bigata
      03.08.2021 15:36
      +1

      Да всё просто коллега. Берете ноут 5-6 летней и запускаете.

      Я матом обкладываю разработчиков, которые написали Web для пары крупных банков, на react. Да, на современном компе с 16Гб, как-то работает, а вот на таком ноуте одни мучения. И это если не глянуть консоль, куда куча инфы зачем-то попадает. И эти поделия в прод выпустили.


      1. Xuxicheta
        04.08.2021 12:39

        Может проблема не в react и ноуте, а в разработчиках?


        1. Bigata
          04.08.2021 13:57

          Конечно в них. Их же матом обкладываю ;) Библиотеки и фреймворки очень сильно понижают порог входа и расхолаживают. + мало кто реально оптимизирует скрипты. Да пофиг что в цикле к бд запросы, да пофиг масиив будем перебирать в лоб, да пофиг ... моного чего ещё.


          1. Xuxicheta
            04.08.2021 13:59
            +1

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


  1. 0xf0a00
    03.08.2021 14:12
    +4

    Ну то есть по сути, от SPA мы не избавляемся, а просто заставляем страдать сервер за всех, вместо устройств пользователей. Отличное решение, вместо плохого SPA у нас теперь будут еще и затраты на мощный сервер что бы все это крутить. Может дело не в SPA а в том что в него пытаются запихать функционала на приличных размеров декстопное приложение, но выполнять это все на JS.


    1. Bigata
      03.08.2021 15:48

      Ну вот в самую точку попали.


  1. Ru6aKa
    03.08.2021 14:38
    +1

    https://habr.com/ru/post/452480/comments/#comment_20174680 - по этой же теме только чуть более подробно с историей вопроса.

    Phoenix LiveView использует чуть хитрее механизм обновления html, в отличии от предшественников они не шлют prepend/append, addClass/removeClass и другие команды для обновления html на стороне клиента, а просто на стороне сервера высчитывают diff и потом его применяют на стороне клиента с помощью morph-dom.

    Да и в плане структуризации кода сейчас все продвинулось намного дальше, в Phoenix LiveView можно использовать компоненты. Причем сейчас активно развивается библиотека компонентов Surface UI.


  1. hardtop
    03.08.2021 15:00
    +1

    Мысль вообще интересная. Особенно для старичков, кто любит и жалует "старый добрый" подход SSR.


  1. Ovoshlook
    03.08.2021 18:29
    +1

    Как интересно наблюдать за тем как Web разработчики открывают для себя транспортные протоколы и идеологии толстых и тонких клиентов спустя десятки лет после их создания...


    1. Revertis
      05.08.2021 13:54

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


  1. BigDflz
    03.08.2021 21:03

    узнал websocket и стал использовать в момент его появления - и удивляюсь, почему его ещё так надо рекламировать? надо просто использовать и наслаждаться простотой и возможностями, которые он предоставляет для web.


  1. AndriyBogdan
    03.08.2021 22:25

    Автор статьи о .Net Blazor вообще ничего не слышал)


  1. gameplayer55055
    03.08.2021 22:25

    Зачем, если есть HTTP3 (QUIC, по сути HTTP2 по UDP)

    Он вообще через udp работает, используя его преимущества, и компенсируя недостатки.

    Можно даже на будущее казать какие страницы понадобятся и их давать. Да и я слышал, что вебсокеты не нужно из-за HTTP2: https://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete


  1. Nnnnoooo
    03.08.2021 22:25

    Как бы все дико это не выглядело, иногда это имеет смысл. Но пихать везде, точно так же дико как и пихать везде, где надо и не надо жирных рич клиентов.


  1. ReDev1L
    03.08.2021 23:36

    https://resgate.io/

    Вам не нужны веб сокеты, им нужен постоянный коннект.


    1. Ovoshlook
      04.08.2021 11:35

      HTTP со времен 1.1 по дефолту использует постоянный коннект. HTTP/2.0 игнорирует заголовок Connection. Браузеры максимально держат соединение до сервиса.

      Ну и неожиданно websocket это обычный tcp. Так что технически нет разнице в транспорте для http и ws.

      У http было одно преимущество перед ws - это реализация на его уровне досылки HTTP сообщений при переустановлении соединения. Чистый ws это просто транспорт и в нем нет этого из коробки. Но во всяких прикладных настройках типа socket.io это уже давно реализовано.


  1. alexyakunin
    03.08.2021 23:43

    Просто отмечу, что будущее давно наступило :)

    https://fusion-samples.servicetitan.com/ - режим Blazor Server там делает все, о чем пишет автор. Режим Blazor WASM делает пререндеринг на сервере, а все остальное - на клиенте.

    Более того, все это обновляется в real-time, и все это делает один и тот же код, в котором вы не увидите практически ничего про real-time - там нет событий и т.п., но обновляется только то, что нужно.

    Демка сделана с:

    Disclaimer: я - автор Fusion.


  1. roma_python
    04.08.2021 06:25

    Мне нравится этот подход, но тогда придется отказаться от progressive applications ибо для них нужна будет отдельная разработка -> ресурсы. Ибо без интернета это все дело не будет работать. А до достаточно быстрого старлинка или его аналогов ещё долго.


    1. diakin
      06.08.2021 14:01

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


      1. diakin
        06.08.2021 23:41

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


  1. RiverFlow
    04.08.2021 13:23
    +1

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

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


    1. k4ir05
      05.08.2021 04:18

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