Build Real-Time Web Apps with Phoenix by Brian P. Hogan

Tags: #<Tag:0x00007f11428ca000>


3 episodes at $6.75 each

Build real-time apps with ease using Phoenix. In this screencast series, get a brief introduction to the Elixir language features you’ll use to build web applications, then create an application that helps you understand Phoenix’s router, controllers, views, and templates. Build a simple model, then explore Phoenix’s Channels as you communicate seamlessly across clients in real time. When you’re done, you’ll have a solid understanding of how to put Phoenix to work in your own projects.

This screencast covers Phoenix version 1.2


This is a great deal. I just watched the first one - pretty basic intro to Elixir. Well done.
Will watch the rest when I get some free time.


It took some time for a few coins to drop before I realized the connection between Exercises for Programmers - 57 Challenges to Develop Your Coding Skills, this tweet, and these videos.


I love how you can purchase each episode individually! Saves me money.


This tutorial is missing the elephant in the room and just gives you the first 1% of what you will need in real life - “sending messages in real-time via websockets” is like being able to send packages via tcp. What you will need very quickly is a sophisticated method to sync data - the author does not mention anything in that direction - very disappointing and far from what I expected. Baby steps.


How one syncs data does massively depend on the scale of data and also on the architecture surrounding this data.

In most cases I’ve encountered so far in (near) real time systems, “syncronizing data” was just having sending data from the “input unit” to a “processing unit” and from there to the “display unit”.

This scales pretty well with the number of input and display units.

Once there are more than one computational units, then I’ve often seen the introduction of data-units. But those make it harder to stay inside of real time requirements and therefore I’ve seen even more often that consistency was dropped in favor of availability…