Chapter 01 :

CONCEPTS / RE-Thinks

• SPA is a distributed system !
• SPAs have shared states.

How Elixir changes SPA?

1. Phoenix Channels = using BEAM for long lived HTTP connections! (as opposed to stateless) - using socket.assigns

   • think of channels as joining channels on slack.

2. sockets function as routers where channel routes are defined. (auto generated by Phoenix)

3. Phoenix.PubSub.PG2 - using BEAM native message passing to broadcaste and coordinate updates – where the complexity adds up in SPA !

   • Leveraging the best of the Erlang VM.

4. Client for requesting data to SPA CAN BE anyone - watch, app, website, IoT !

• Anyone who subscribes to a channel → topic:subtopic is a client.

5. Standard (read : best practices) infrastructure to deal with auth.
6. Buggy network connections => Phoenix uses ETS-tables (BEAM’s strength) to ensure fault tolerance!

Source : from Chapter 01 + Channels — Phoenix v1.5.12.

Happy Reading!

Nice one TT! I am sure a lot of people are going to be interested in following your journal!