1, the introduction of

Launched in March 2019 by the Phoenix team, a back-end rendering framework is designed to enable developers to create real-time interactive Web applications with minimal cost.

LiveView provides a rich real-time user experience through HTML rendered by the server.

Once the state changes, LiveView will re-render the relevant part of its HTML template and push it to the browser, which will update itself in the most efficient way possible. This means that developers can write LiveView templates just like any other server rendered HTML, and LiveView keeps track of changes and sends the differences to the browser.

2, the background,

(1) Common real-time user interaction experience:

(1) The search box is automatically completed

② Form real-time verification

③ Live chat

(2) Existing solutions:

1) SPA (Single Page Application)

Apps: Google Docs and Figma (Browser-based interface design collaboration tool)

Advantages: Achieve the most complex interactive and animation effects today, can be used offline

Disadvantages: Front and back end separation, inefficient development, not SEO friendly

② AJAX Application (server API+JQUERY)

Example: Ruby on Rails, Phoenix(Without LiveView)

Application: Gmail

Advantages: Relatively low initial code complexity, high development efficiency, SEO friendly

Disadvantages: Weak real-time performance, data update is usually obtained by refreshing the interface, and the request speed is slow (data is reacquired after each refresh)

③ Between the two

Examples: Turbolinks, Stimulus

Application: Basecamp

Development efficiency and real time are between single interface applications and AJAX applications

Conclusion:

3. Phoenix LiveView principle

① Browsers connect with LiveViewChannel via WebSockets, send PHX prefix event information to send a Channel

GenServer calls defined in Channel define handle_Event /callback to update data in live Module

(3) After the data is updated, return a tuple to return the new data to the channel

④ Call the LiveViewDiff module for diff operations to see which updates need to be returned to the front end

⑤ Return some updates to channel

⑥ A channel pushes diff updates or redirects to the front-end browser

⑦ The browser through the morphdom module for the front-end diff patch operation and trigger JS hooks

4. Advantages of LIveView

(1) Meet most real-time interaction requirements

① Real-time UPDATES of CRUD operations => Twitter Timeline

② The server actively pushes data updates to the client => Phoenix Live Dashboard

③ Provide JavaScript Hook functions for customization => Infinite Scroll

(2) Efficient development experience

The amount of code is small, without considering how to design the request path of the back-end API, the structure of the returned data, how to track data changes, how to notify the client of data updates, how to receive API parsing and dom updates in the front end and other non-core parts.

Livevie realizes the management of data state changes and only needs to focus on the core part in the development.

(3) Extreme performance

(1) The DIff mechanism is efficient, and there is still room for optimization

Render will distinguish between static and dynamic content, when the state occurs, static unchanged, dynamic change

Only dynamically changing data diff is transmitted, further reducing the payload size

Erlang Term Format(ETF) native Format support, server load capacity increase and reduce packet size

② The vertical expansion is guaranteed by Phoenix Channel

Up to 200W websockets can be supported simultaneously on a 40-core, 128GB server

③ Horizontal expansion is guaranteed by Erlang OTP

Connect multiple machines to form a cluster

(4) SEO friendly

① The first rendering returns a complete HTML response by default, so both browsers and crawlers can get the complete data

(2) After the end of HTML rendering, WebSocket connection to start the LiveView life cycle, to ensure the normal update of browser data

5. Disadvantages of LiveView

Mainly due to WebSocket dependency

① Cannot be used offline => Complex local applications (example: Figma)

② User experience is easily affected by delay => games, animation effects

  • Animation – Animations, menus, and general UI events that do not require a server in the first place are not suitable for LiveView. These can be implemented without LiveView in a variety of ways, such as using CSS and CSS transformations, using LiveView hooks, and even integrating with UI toolkits designed for this purpose, such as Bootstrap, Alpine.JS, etc.

Official team tried to solve, cache, opening animation and other improvements to delay effect, offline state of the cache.