Phoenix LiveView: когда вам больше не нужен JavaScript*

* для создания динамической страницы

Не так давно 12.12.2018 был анонсирован ^[1] выход новой библиотеки для фанатов phoenix framework под названием Phoenix LiveView ^[2]. Я бы хотел поделиться с вами впечатлениями от ее использования и phoenix в целом, а в следующей статье попробовать написать простую браузерную игру. Часть статьи с личным мнением не является исключительно правдивой, я попробую объяснить преимущества веб-разработки на примере phoenix vs php

Теоретическая часть

Phoenix LiveView — это потрясающая новая библиотека, которая позволяет создавать динамические веб-страницы без написания javascript кода посредством двунаправленной связи по вебсокетам и server side rendering. Как мы прекрасно знаем, вебсокеты у phoenix достаточно хорошо реализованы ^[3], поэтому производительности хватит для большинства идей, которые вы планируете реализовать.

Существует несколько вариантов использования LiveView:

• Проверка ввода данных в формы (валидация), нажатие кнопок, скрытие и отображение блоков, автозаполнения.
• События от сервера, такие как уведомления, информационные панели, счетчики.

В данный момент с ограничениями доступны и приоритетны в будущем:

• Навигация по страницам и пагинация. Они могут быть построены с помощью LiveView, но в настоящее время вы потеряете функционал перехода «назад / вперед». Поддержка `pushState` включена в план.
• Отображение постоянно растущих данных — чаты, онлайн логи и т.п. можно создавать с помощью LiveView, но в настоящее время вы должны хранить все данные в состоянии приложения на сервере. Поддержка частичного обновления данных состояния находится в разработке.
• Работа с задержками при изменении состояния. LiveView хранит состояние приложения на стороне сервера и это гарантирует правильную работу интерфейса при серьезных задержках.
• Полный набор функций для моделирования этих ситуаций появится в будущих версиях.

В чем плох LiveView:

• Анимации. К примеру отображение меню по клику можно реализовать через LiveView, но плавное появление лучше отдать в css или js.
• Optimistic UI. Приложение рассчитано на постоянную работу с стейтом сервера и этого стейта нет на клиенте. Весь html код на любое событие подготавливается на сервере с новым состоянием и летит по вебсокетам к клиенту, все видимые изменения происходят посредством подмены html кода.

Как работает LiveView?

Изображение взято с elixirschool ^[4]

LiveView начинается с обычного HTTP-запроса и HTML-ответа, а затем приступает к отслеживанию состояния приложения на сервере через вебсокеты, при этом гарантируя отображение обычной HTML-страницы, даже если JavaScript отключен. Каждый раз, когда состояние приложения меняется, оно автоматически перерисовывает отображение и обновления передаются клиенту. На клиенте при помощи библиотеки morphdom ^[5] происходит обновление контента. По сути, логика достаточно близкая к современным js фрэймворкам, только без использования virtual DOM.
Чтобы сеанс связи не терялся при повторном подключении, из контроллера инициируется «сессия» пользователя с необходимыми данными и передается клиенту. Только подписанная сессия с первичными данными хранится на клиенте, она отправляется на сервер при подключении, или повторном подключении в случае сбоя, к состоянию приложения.

Впечатление и личное мнение о самом Phoenix

Из личного опыта скажу, что редко встречал понятно написанные приложения в командах от 3х и более человек. Часто встречается мешанина из сервисов на php)(сервер) nodejs (websocker) react/vue (фронт) туда еще и go засунут для вещей, которые «медленно» работают на php. Очереди мы в redis засунем, потом подключим rabbitmq, а один из разработчиков не умеет ими пользоваться и реализовал в sql. Кто-то умеет правильно пользоваться кроном через flock и не городит логику защиты повторного запуска в коде, а другие запускают демоны на php, что иногда вставляет палки в колеса при обновлении кода и структуры бд. Состояние приложения начинает хранится везде и всюду, в статике класса, в синглтоне, порой даже в статической переменной метода, начинают множится правила написания кода чтобы бороться с незнанием языка и правильным построением архитектуры, но что если проект начинал программист уровня middle или junior на коленке, не задумываясь что это все вырастет до настоящего бизнеса? Поддерживать такое в одиночку не так просто, часть логики дублируется как на клиенте, так и на сервере (валидация к примеру). В SPA, когда фронт начинает использовать публичное api, мы начинаем задумываться о версионировании. Поддержка усложняется т.к. приходится удовлетворять не только нужды внешних сервисов и клиентов, но и свой часто изменяемый фронт, а дублировать код не хочется. Прикручивам graphql. Со временем зоопарк библиотек разрастается и фирмы начинают нанимать больше разработчиков.

Тут я и вижу превосходство phoenix. Из коробки у нас php (Phoenix), nodejs (вебсокеты на Phoenix.Socket), react/vue (Phoenix.LiveView), redis(ets), rabbitmq (ets), cron (возможно через GenServer), демоны (GenServer), урезанная бд (mnesia). У нас кеширование в самом языке через mnesia или ets, крон или демоны вообще без проблем т.к. многозадачность и работа в фоне годами у «эликсира в крови». Хранение состояния чаще всего в генсервере. Публичное api исключительно для нужд внешних сервисов, spa в скором времени будут писаться на LiveView. Поддержка api станет куда проще. Масштабируемость в любое направление средствами языка, скорость работы ограничена только источником хранения данных, все остальное работает весьма быстро. Достаточно понятная схема работы если один раз узнать как работает plug и что такое conn. Генерация кода, «микросервисная архитектура» — посмотрите в сторону umbrella application. Это все пытаются решить докерами с оркестрацией и т.п. создавая рабочие места для большого количества devops инженеров.

Итог

Попробуйте установить elixir и запустить phoenix. В этой статье я постарался изложить «воду», личное мнение и теоретическую часть, чтобы в следующей ограничится исключительно кодом и логикой. Мы будем писать простую игру на LiveView формата dogeminer но без функциональности кликера. Это моя первая статья, прошу строго не судить и не воспринимать чрезмерно серьезно, я намеренно однобоко показал достоинства Phoenix и упустил его недостатки. Их лучше ощущать на практике чем вот так на мнении чужого человека.

Присоединяйтесь к русскоязычному сообществу elixir разработчиков proelixir ^[6] или находите в telegram @proelixir. Свежие новости языка собирает бот на канале @proelixir_news.

Автор: yaBliznyk

Источник ^[7]