Phoenix LiveView: when you no longer need JavaScript *
Not so long ago, on 12/12/2018, the release of a new library for phoenix framework fans called Phoenix LiveView was announced . I would like to share with you my impressions of its use and phoenix in general, and in the next article try to write a simple browser game. The part of the article with a personal opinion is not exclusively true, I will try to explain the advantages 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 through bidirectional communication on web sockets and server side rendering. As we well know, phoenix web sockets are well implemented , so there will be enough performance for most of the ideas that you plan to implement.
There are several options for using LiveView:
- Checking the input of data into forms (validation), pressing buttons, hiding and showing blocks, auto-complete.
- Events from the server, such as notifications, dashboards, counters.
Currently limited and available in the future:
- Page navigation and pagination. They can be built using LiveView, but at the moment you will lose the functionality of the transition "back / forward". Support for `pushState` is included in the plan.
- Display constantly growing data - chats, online logs, etc. can be created using LiveView, but currently you must store all the data in the state of the application on the server. Support for partial updating of status data is under development.
- Work with delays when a state changes. LiveView stores the state of the application on the server side and this ensures the correct operation of the interface with serious delays.
- A complete set of functions for modeling these situations will appear in future versions.
What is bad about LiveView:
- Animations For example, the menu display by click can be implemented via LiveView, but a smooth appearance is better to give in css or js.
- Optimistic UI. The application is designed to work continuously 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 through web sockets to the client, all visible changes occur by replacing the html code.
How does liveview work?
Image taken from elixirschool
LiveView starts with a normal HTTP request and an HTML response, and then proceeds to monitor the status of the application on the server via web sockets, while guaranteeing the display of a regular HTML page, even if JavaScript is disabled. Each time the application state changes, it automatically redraws the display and updates are sent to the client. On the client, using the morphdom library, content is updated. In fact, the logic is quite close to modern js frameworks, only without using virtual DOM.
To prevent the communication session from being lost when reconnecting, a user session with the necessary data is initiated from the controller and transmitted to the client. Only a signed session with primary data is stored on the client, it is sent to the server when connecting, or reconnecting in case of failure, to the state of the application.
Impression and personal opinion about Phoenix itself
From personal experience, I’ll say that I rarely met clearly written applications in teams of 3 or more people. Often there is a mishmash of services on php (server) nodejs (websocker) react / vue (front) there go also put in for things that work "slowly" on php. We will put the queues in redis, then we will connect rabbitmq, and one of the developers does not know how to use them and implemented it in sql. Someone knows how to correctly use the crown via flock and does not make the re-launch protection logic in the code, and others run daemons in php, which sometimes puts sticks in the wheels when updating the code and structure of the database. The application state begins to be stored everywhere and everywhere, in class statics, in singleton, sometimes even in a static method variable, rules for writing code begin to multiply in order to combat ignorance of the language and the correct construction of the architecture, but what if the project was started by a middle or junior programmer on the knee, without thinking that it would all grow into a real business? Maintaining this alone is not so easy, 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 the public api, we begin to think about versioning. Support is getting harder because you have to satisfy not only the needs of external services and customers, but also your often-changing front, and you don’t want to duplicate the code. Screwed graphql. Over time, the zoo of libraries grows and firms begin to hire more developers. and on the server (validation for example). In SPA, when the front begins to use the public api, we begin to think about versioning. Support is getting harder because you have to satisfy not only the needs of external services and customers, but also your often-changing front, and you don’t want to duplicate the code. Screwed graphql. Over time, the zoo of libraries grows and firms begin to hire more developers. and on the server (validation for example). In SPA, when the front begins to use the public api, we begin to think about versioning. Support is getting harder because you have to satisfy not only the needs of external services and customers, but also your often-changing front, and you don’t want to duplicate the code. Screwed graphql. Over time, the zoo of libraries grows and firms begin to hire more developers.
Here I see the superiority of phoenix. Out of the box, we have the replacement php (elixir + Phoenix), nodejs (websockets on Phoenix.Socket), react / vue (Phoenix.LiveView), redis (ets), rabbitmq (ets), cron (possibly via GenServer), daemons (GenServer ), truncated database (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 for years at the "elixir in the blood." State storage is most often in the gene server. Public api exclusively for the needs of external services, spa will soon be written on LiveView. Support for api will be much easier. Scalability in any direction by means of the language, the speed of work is limited only by the source of data storage, everything else works very quickly. A fairly clear working scheme if you once learn how the plug works and what conn is. Code generation "Microservice architecture" - look towards the umbrella application. They are trying to solve all this with 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 in the next I will limit myself solely to code and logic. We will be writing a simple game on DogView's DogView format but without clicker functionality. This is my first article, I ask you not to strictly judge and not take it too seriously, I intentionally one-sidedly showed the advantages of Phoenix and missed its shortcomings. It is better to feel them in practice than like this on the opinion of a stranger.
Join the proelixir developers community in elixir or find @proelixir on telegram. Fresh language news is collected by the bot on the channel @proelixir_news.