Journal : Programming Phoenix LiveView

I have read first chapter. Will add my notes / code tries / self exploration as I go along!

Thank you @AstonJ for encouraging to start it.
I hope I’ll be able to finish the book in a couple of months.

Stay tuned!

2 Likes

Corresponding tweet for this thread:

Share link for this tweet.

2 Likes

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 channeltopic:subtopic is a client.
  1. Standard (read : best practices) infrastructure to deal with auth.
  2. 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!

3 Likes

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

1 Like