Одна из проблем, возникающих из-за модели LiveView с сохранением состояния, — какие моменты следует учитывать при развертывании новой версии LiveView (или при восстановлении после ошибки).

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

Однако при таком переходе LiveView может потерять часть состояния. Как с этим быть? Хорошая новость заключается в том, что есть несколько практик, которые помогут не только при развертывании, но и улучшат ваше приложение в целом.

1. Если это уместно, храните состояние в параметрах запроса. Например, если в приложении есть вкладки и пользователь нажал на одну из них, вместо использования phx-click и Phoenix.LiveView.handle_event/3 для управления ими реализуйте эту функциональность с помощью <.link patch={...}>, передавая название вкладки в качестве параметра. Затем вы получите название новой вкладки через Phoenix.LiveView.handle_params/3, которая задаст нужное значение assign, чтобы выбрать отображаемую вкладку. Можно даже определить отдельные URL-адреса для каждой вкладки в маршрутизаторе приложения. Так вы сократите объем состояния на сервере, сделаете навигацию по вкладкам доступной по ссылкам, улучшите индексацию поисковыми системами и многое другое.

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

3. Если в приложении используются формы (а скорее всего, так и есть), помните, что Phoenix автоматически восстанавливает данные форм: при отключении Phoenix соберет данные формы и отправит их повторно после восстановления подключения. Этот механизм работает из коробки с большинством форм, но для самых сложных форм может потребоваться настроить его или проверить его работу. Подробнее см. соответствующий раздел документа «Привязки форм».

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

Если у вас действительно есть сложное состояние, которое нельзя обработать сразу, возможно, придется прибегнуть к специальным стратегиям. Например, сохранять «старое» состояние в Redis/S3/базе данных и загружать новое состояние при установлении новых подключений. Или же уделить особое внимание переносу подключений (например, если вы разрабатываете игру, можно дождаться окончания текущих сеансов, прежде чем отключать старый сервер, направляя новые сеансы на новые серверы). Такие случаи зависят от ваших требований (и, скорее всего, возникли бы независимо от используемого стека приложения).