TeamGenik is made with Elixir and Phoenix LiveView

Programming language Elixir

TeamGenik's core system is written in Elixir, a functional programming language.

Elixir is a new language born in 2012. Compared to C born in 1972, Python born in 1991, Java born in 1995, Ruby, etc., it is not yet known, but it is gaining popularity in the field of Web and IoT. InfoQ's Programming Languages InfoQ Trends Report, released in October 2019, says Elixir has entered the innovator phase.

Phoenix Framework

TeamGenik uses the Phoenix Framework (Phoenix), an Elixir-based web application development framework.

Phoenix is heavily influenced by Ruby on Rails. In particular, the routing and controller mechanisms are very similar. The library Ecto that Phoenix uses for database operations is similar to Active Record. For those of us familiar with Ruby on Rails, Phoenix was a very natural choice.

Phoenix LiveView

TeamGenik uses Phoenix LiveView to render HTML code. Phoenix LiveView generates HTML code in two steps:

• In response to events that occur outside the app, the app's state is converted to a new state.
• Detects changes in state and generates HTML code.

Phoenix LiveView provides a constant connection between the browser and the server via WebSocket.

Phoenix LiveView sends only the difference generated in the HTML code due to the change in state to the browser, so the amount of communication between the browser and the server can be kept low.

New trends in single page application (SPA) development

TeamGenik is built as a single page application (SPA). In other words, instead of causing a screen transition each time a user clicks a link, a part of the screen is changed on the spot.

In the late 2010s, SPA development flourished, and JavaScript frameworks such as React, Angular, and Vue became widely used.

However, we adopted Phoenix LiveView in anticipation of the trend since the 2020s. SPA development with Phoenix LiveView is very different from the previous one in that it is server side centered.

The figure above compares the system configuration using the JavaScript framework with the system configuration using Phoenix LiveView. The two ellipses written as State represent the data (state) held by the application. HTML code is generated from this State in any system configuration. When the State changes due to user operations, the HTML code changes accordingly, and the browser screen changes.

In the left system configuration, State is on the browser. In order to rewrite this State and generate HTML code from State, a large JavaScript program will run on the browser. On the other hand, in the system configuration using Phoenix LiveView on the right, State is on the server side. The Elixir program is running on the server, rewriting State and generating HTML code from State. It connects with a small JavaScript program that runs on the browser using WebSocket, receives events from the browser, and sends HTML code differences to the browser.

There are four main reasons that the focus of development has shifted from the front end (browser side) to the server side:

• Programming using JavaScript, a non-functional language, is almost unnecessary. In other words, almost the entire system can be developed in one kind of language (Elixir).
• It is not necessary to implement an API that receives inquiries from the front end.
• It is no longer necessary to create the same type of functions (validation etc.) on the front end and server side.
• Malicious users can't analyze JavaScript source code to get system attack hints or reveal trade secrets.

Of course, there are things that you lose. Moving some of the processing that was done on the user's computer to the server side means increasing the burden on the server. It also increases the amount of communication that occurs between the front end and the server side. Also, if the browser and server are separated by a network, users may feel more responsive.

We believe that these shortcomings will be overcome as the development and acceptance of Phoenix LiveView progresses. After all, version 0.1 was just released in August 2019 and has not yet reached version 1.0.

LiveView Socket has a one-to-one correspondence with browsers

In traditional web systems, a small number of web applications respond to access from a very large number of browsers (see below).

One Web application processes requests from multiple browsers in order. Also, it is not constant which Web application is responsible for requests from a certain browser. As a result, Web applications cannot hold specific browser-specific data. The data is stored in the database or in the State on the browser.

On the other hand, in the system using LiveView, LiveView Socket has a one-to-one correspondence with the browser as shown in the following figure. Both are always connected via WebSocket.

Each LiveView Socket is so small that it can continue to run thousands or even tens of thousands on a single server. And each LiveView Socket has a unique State.

In this way, using Phoenix LiveView fundamentally changes the way web systems are created.