Phoenix LiveView: when you no longer need javascript *

* to create a dynamic page

Not so long ago, on 12/12/2018, the release of a new library for fans of the phoenix framework called Phoenix LiveView was announced . I would like to share with you my impressions of its use and phoenix as a whole, and in the next article try to write a simple browser game. Part of the article with a personal opinion is not exclusively true, I will try to explain the benefits of web development using the example of phoenix versus php

Theoretical part

Phoenix is a framework in the functional language elixir . Please do not confuse with Phalcon for php.

Phoenix LiveView is a terrific new library that allows you to create dynamic web pages without writing javascript code via bidirectional communication via web socket servers and server side rendering. As we know very well, phoenix has the webboxes that are fairly well implemented , so there will be enough performance for most of the ideas you plan to implement.

There are several options for using LiveView:

• Verification of data entry in the form (validation), pressing buttons, hiding and displaying blocks, autocomplete.
• Events from the server, such as notifications, dashboards, counters.

Currently available with limitations and priorities in the future:
')

• Navigation through pages and pagination. They can be built using LiveView, but currently you will lose the functionality of the "back / forward" transition. `PushState` support is included in the plan.
• Display of constantly growing data - chats, online logs, etc. You can create it using LiveView, but now you have to store all the data in the application state on the server. Support for partial status updates is under development.
• Work with delays when changing state. LiveView stores the state of the application on the server side and this ensures the correct operation of the interface with serious delays.
• A full set of features to simulate these situations will appear in future versions.

What is bad LiveView:

• Animations. For example, a menu display on click can be implemented through LiveView, but a smooth appearance is better to give in css or js.
• Optimistic UI. The application is designed for permanent work with the server state and this state is not on the client. All html code for any event is prepared on the server with a new state and flies over the web socket to the client, all visible changes occur by changing the html code.

How does liveview work?

Image taken from elixirschool

LiveView starts with a regular HTTP request and an HTML response, and then proceeds to monitor the status of the application on the server via web-sites, while ensuring that the usual HTML page is displayed, even if JavaScript is disabled. Each time the state of the application changes, it automatically redraws the display and updates are sent to the client. The content is updated on the client using the morphdom library. In fact, the logic is quite close to modern js frameworks, but without using virtual DOM.
So that the communication session is not lost when reconnecting, a “session” of the user with the necessary data is initiated from the controller and transferred to the client. Only a signed session with primary data is stored on the client, it is sent to the server when connected, or reconnected in case of failure, to the state of the application.

Impressions and personal opinions about Phoenix itself

From personal experience I will say that I rarely met clearly written applications in teams of 3 or more people. Often there is a hodgepodge of services on the php (server) nodejs (websocker) react / vue (front) and there they also go and shove them for things that “slowly” work on php. We will fire queues in redis, then we will connect rabbitmq, and one of the developers does not know how to use them and implemented them in sql. Someone knows how to properly use the crown through the flock and does not frighten the restart protection logic in the code, while others launch demons in php, which sometimes inserts sticks into the wheels when updating the code and structure of the database. The state of the application begins to be stored everywhere and everywhere, in the class static, in the singleton, sometimes even in a static method variable, the rules of writing code begin to multiply to fight language ignorance and proper architecture building, but what if the project was started by a middle or junior programmer on the knee, without thinking that this will all grow to a real business? It’s not so easy to maintain this alone, part of the logic is duplicated both on the client and on the server (validation for example). In SPA, when the front begins to use public api, we begin to think about versioning. Support becomes more complicated. you have to satisfy not only the needs of external services and customers, but also your often changing front, but you don’t want to duplicate the code. Attached graphql. Over time, the library zoo is growing and firms are starting to hire more developers.

Here I see the superiority of phoenix. Out of the box we have php replacement (elixir + Phoenix), nodejs (web sockets for Phoenix.Socket), react / vue (Phoenix.LiveView), redis (ets), rabbitmq (ets), cron (possibly via GenServer), daemons (GenServer ), abridged DB (mnesia). We have caching in the language itself through mnesia or ets, crowns or demons without any problems at all. multitasking and work in the background over the years at the "elixir in the blood." State storage is most often in the general server. Public api exclusively for the needs of external services, spa will soon be written on LiveView. Api support will be much easier. Scalability in any direction by means of the language, speed is limited only by the source of data storage, everything else works very quickly. A fairly clear scheme of work if you once know how a plug works and what conn is. Code generation, “microservice architecture” - look towards umbrella application. This is all trying to solve dockers with orchestration, etc. creating jobs for a large number of devops engineers.

Total

Try installing elixir and running phoenix. In this article I tried to state the “water”, personal opinion and theoretical part, so that the next one will be limited to code and logic only. We will write a simple game on LiveView of the dogeminer format but without the functionality of the clicker. This is my first article, please do not strictly judge and do not take it too seriously, I deliberately showed one-sided advantages of Phoenix and missed its shortcomings. It is better to feel them in practice than on the opinion of a stranger.

Join the Russian community of elixir developers proelixir or find in telegram @proelixir. Fresh news of the language collects the bot on the channel @proelixir_news.