How to deploy a simply Phoenix LiveView + Ecto app to fly.io
4 Likes
How to compose and refactor Ecto queries with Queries Modules
4 Likes
I recently started a blog series called “Open-source Deep Dive” where I analyse open-source projects & share my findings about them and I have published my second article in this series!
In this second installment, Broadway takes center stage! Broadway is an Elixir library for building data processing pipelines for data sources like message queues.
The article is broken down into two parts.
- Part one goes over the general concepts used in Broadway like message queues and concurrency in Elixir. It also breaks down the architecture of a pipeline.
- Part two dives into the implementation of certain features like rate limiting and graceful shutdowns.
Any feedback would be amazing! Thanks! 
4 Likes
Nice blog. It would be even better to provide a RSS feed though.
2 Likes
I am working on adding RSS support to my blog now! Thanks for the suggestion!
1 Like
I wrote about the elixir AST, and leveraged it to build a typed struct macro and a credo-like static code checker.
5 Likes
3 Likes
2 Likes
I just published a blog post on:
How to implement U2F Authentication with Phoenix LiveView
In particular, I register a YubiKey 5 and log in through it. This blog post took quite a bit of work, but I hope that you enjoy it and find helpful 
6 Likes
thank you for your detailed article on this subject and one suggestion you could have given some details and examples on references in migration files,
i did whatever you guided on the article everything in 30 minutes and i spent a week to fix references part in migration file, i was missing to add “type: :uuid”
add(:user_id, references(:users, type: :uuid, on_delete: :delete_all), null: false)
but finally i fixed it
I hope this story can help someone avoid the same mistakes 
9 Likes
If you are installing Phoenix JS libraries from NPM, you might find this post useful
1 Like
Very interesting and informative. I read it almost like a thriller. 
Thanks 
1 Like
We learn best from errors,but obviously most blog-posts are shiny success-stories. So thanks for your courage to share this!
2 Likes
So dozens of updates per second through pubsub is ok, it is just the live view process cannot keep up, right?
Would it make sense to store the participants info in ETS and just send a simple :updated message to the liveview, and within the liveview it can selectively peek forward the message queue and collapse all the :updated messages, grab the participants from ETS then render just once?
The issue really ended up being a combination of these things: payloads too large, updates too frequent, processing in the LV process too slow.
And while I haven’t gone for ETS just yet, I did change it from {:participants_updated, participants_list} to just :participants_updated plus an explicit fetch from the LV.
Once your message is converted to just a notification, you can do a receive loop and cull all the participants_updated messages in the queue, then fetch the list once, render the html once. If you have the actual page render and the diff sent, the bottleneck should not be the client side anymore. The inbox of the LV process should be under control due to the smaller messages and the message coalescing.
1 Like
I found throttling the update messages at the sender level to be a nicer solution. Instead of having the LV account for an excessive amount of messages, I prefer making the sender “play nice”
