Comments 21
Т.е. новый виток в создании более тормозных сервисов?
На чем основано утверждение? Вы пробовали live view?
Просто все стараются переносить часть обработки на сторону клиента, но никак не на сервер.
При этом необходимо создавать копию состояния и налаживать синхронизацию. К тому же необходим JS программист.
Для стартапа быстрый выход на рынок — это наивысший приоритет. К тому же бюджет не всегда позволяет иметь полноценную команду. Вот тут Phoenix + LiveView будут идеальным вариантом.
В дальнейшем, если база пользователей будет уже серьёзной, то и деньги должны быть и команду можно побольше нанять. Тогда уже вопрос оптимизаций и т.п. будет актуален.
Так что рынок для этого решения огромный.
Но сейчас я столкнулся с тем, что молодые backend программисты не готовы (да и не умеют) верстать HTML и стили :) Вот это уже другая проблема.
Для стартапа быстрый выход на рынок — это наивысший приоритет. К тому же бюджет не всегда позволяет иметь полноценную команду. Вот тут Phoenix + LiveView будут идеальным вариантом.
В дальнейшем, если база пользователей будет уже серьёзной, то и деньги должны быть и команду можно побольше нанять. Тогда уже вопрос оптимизаций и т.п. будет актуален.
Так что рынок для этого решения огромный.
Но сейчас я столкнулся с тем, что молодые backend программисты не готовы (да и не умеют) верстать HTML и стили :) Вот это уже другая проблема.
Нет, это что-то типа «php пытается выглядеть более живым и полезным, чем он есть».
Полный server-side rendering в ряде задач будет вполне уместен. А в ряде других задач — да, будет тормозным и убогим поделием, требующим непрерывной связи с сервером, и желательно, чтоб сервер стоял в соседней комнате (чтоб latency поменьше).
Полный server-side rendering в ряде задач будет вполне уместен. А в ряде других задач — да, будет тормозным и убогим поделием, требующим непрерывной связи с сервером, и желательно, чтоб сервер стоял в соседней комнате (чтоб latency поменьше).
Сперва происходит рост уровня взаимодействия за счёт раздувания инфраструктуры — потом схлопывание инфраструктуры без потери уровня взаимодействия.
Так что да, мы вроде как на новом витке)
Вообще по сути это третья реализация подходов которые были использованы в nitrogen, старогом erlang фреймворке.
Первая реализация была в виде CMS zotonic, в которой под капотом такой же подход как и в nitrogen.
Вторая реализация в виде n2o erlang фреймворка, по сути это переписанный с нуля nitrogen, с вебсокетами и разными вариантами кодирования сообщений.
Третья реализация и скорее всего не последняя от команды разработчиков Phoenix.
Подход очень простой:
1. Сервер отдает сгенерированный html клиенту. В котором все элементы с которыми взаимодействует пользователь (кнопки, выпадающие списки, поля ввода и т.д.) кроме уникальных id (сгенерированных на стороне сервера), содержат js код для отправки payload(нагрузка с данным или просто событием) на сервер…
2. При получении события на стороне сервера происходит декодирование нагрузки, подготавливается ответ, и отправляется клиенту.
3. При получении клиентом сообщения от сервера происходит выполнение кода, как правило это prepend/append, addClass/removeClass, так же может поменять значение элемента или заменить весь блок.
Плюсы такого подхода:
1. Состояние коннекта храниться на сервере, и поэтому не теряется при перезагрузке, так же отпадает надобность в хранилище состояние для фронтенд фрейморка.
2. Для данных которые постоянно дописываются в конец, нету лишнего преобразования данных, с сервера прилетает уже готовый html (в случае фронтенд фрейморков, сервер отдает данные в json, а фреймворк эти данные добавляет в дерево).
3. Для долгих задач на стороне сервера, не надо писать особую логику. Если пользователь закрыл вкладку, то пришедшие данные просто ничего не поменяют.
4. Для клиентов с выключенных js, отдается уже готовый контент, пускай и с урезанной интерактивностью.
Да есть и минусы:
1. Основной минус, что шаблоны и данные идут в перемешку, можно забыть про MVC и прочие патерны.
2. На каждое действие пользователя летит событие на сервер и ответ обратно, при плохой сети это может вызывать проблемы с интерактивностью приложения.
Первая реализация была в виде CMS zotonic, в которой под капотом такой же подход как и в nitrogen.
Вторая реализация в виде n2o erlang фреймворка, по сути это переписанный с нуля nitrogen, с вебсокетами и разными вариантами кодирования сообщений.
Третья реализация и скорее всего не последняя от команды разработчиков Phoenix.
Подход очень простой:
1. Сервер отдает сгенерированный html клиенту. В котором все элементы с которыми взаимодействует пользователь (кнопки, выпадающие списки, поля ввода и т.д.) кроме уникальных id (сгенерированных на стороне сервера), содержат js код для отправки payload(нагрузка с данным или просто событием) на сервер…
2. При получении события на стороне сервера происходит декодирование нагрузки, подготавливается ответ, и отправляется клиенту.
3. При получении клиентом сообщения от сервера происходит выполнение кода, как правило это prepend/append, addClass/removeClass, так же может поменять значение элемента или заменить весь блок.
Плюсы такого подхода:
1. Состояние коннекта храниться на сервере, и поэтому не теряется при перезагрузке, так же отпадает надобность в хранилище состояние для фронтенд фрейморка.
2. Для данных которые постоянно дописываются в конец, нету лишнего преобразования данных, с сервера прилетает уже готовый html (в случае фронтенд фрейморков, сервер отдает данные в json, а фреймворк эти данные добавляет в дерево).
3. Для долгих задач на стороне сервера, не надо писать особую логику. Если пользователь закрыл вкладку, то пришедшие данные просто ничего не поменяют.
4. Для клиентов с выключенных js, отдается уже готовый контент, пускай и с урезанной интерактивностью.
Да есть и минусы:
1. Основной минус, что шаблоны и данные идут в перемешку, можно забыть про MVC и прочие патерны.
2. На каждое действие пользователя летит событие на сервер и ответ обратно, при плохой сети это может вызывать проблемы с интерактивностью приложения.
хранить состояние на сервере это дорогое удовольствие, это постоянная запись нового состояния. Постоянное чтение — это нормально, это быстро, а постоянная запись это просто долго. Состояние клиентского интерфейса надо хранить на клиенте, пусть он у себя перезаписывает и рендерит своё состояние, серверу зачем этим заниматься? Что бы обойтись толко PHP и не искать JS программиста?
При чем тут вообще PHP?
В статье автор запутался и запутал читателей. Во многих местах упоминается php. Вплоть до:
При это у php есть несколько созвучный Phalcon.
Тут я и вижу превосходство phoenix. Из коробки у нас php (Phoenix), ...
При это у php есть несколько созвучный Phalcon.
> Из коробки у нас php (Phoenix)
Видимо, читатели не знакомые близко с предметом статьи, интерпретировали эту фразу буквально :)
Видимо, читатели не знакомые близко с предметом статьи, интерпретировали эту фразу буквально :)
Возможно, автор написал запутано, но вроде как нигде он не запутался.
Из коробки у нас php (Phoenix), nodejs (вебсокеты на Phoenix.Socket), react/vue (Phoenix.LiveView), redis(ets)
Почему php(Phoenix) может запутать, если перечисление продолжается, и из него видно противопоставление? Так можно подумать что разговор идет и про nodejs фреймворк. Или даже одновременно про PHP и Nodejs фреймворк (как бы это парадоксально не звучало)...
Но в принципе, можно было и попонятнее сформулировать, в этом я с вами согласен
UFO just landed and posted this here
Only those users with full accounts are able to leave comments. Log in, please.
Phoenix LiveView: когда вам больше не нужен JavaScript*