I published this post yesterday about how to use head and tail. It’s fairly basic stuff, but I tried to cover it as in-depth as possible.
How to use verified routes in Phoenix 1.7+
1 Like
Saw this from my Rust news feed and thought it was pretty nice intro to rustler:
Learn how to listen to changes in your database right from your Elixir app using Postgres Triggers!
This is handy if you can’t use PubSub to broadcast changes, for example, if another app changes your database.
2 Likes
I wrote about a library that Evadne Wu released last year which has escaped the attention of the Elixir community so far.
A post was merged into an existing topic: Blog Post: Elixir for JavaScript developers: first impressions
Resilience and Fault Tolerance are concepts that should be present in our everyday development approach. What happens if we mix that up with high concurrency? In this blog post, I wrote for Finiam, I share an insight into these topics and a simple Framework on how to do it.
4 Likes
That’s a phenomenal article. Really makes setting up a supervision tree crystal clear. It makes me wonder if there is any sort of community “cookbook” where “recipes” like that are shared, something like Rust’s cookbook.
Thanks! Not that I’m aware of… Maybe there is, and we’re both missing out 
If you end up finding something about that, feel free to reach out!
nice article
1 Like
We’ve recently found a nice use case for a mini DSL in our application and have published a blog post how we used macros to get consistent authorization.
Can’t Live with It, Can’t Live without It!
'With’ is a powerful tool in Elixir, but it’s not without its quirks. This blog will help you understand how to use it best and how to manage unexpected behaviours.
3 Likes
I recently rebuilt my website in Phoenix Elixir 1.6.5 and I’m thinking about doing a tutorial series on how I did it. What are your thoughts on a full nuts and bolt deep dive tutorial?
Bumblee & Stable Diffusion & Phoenix Live View meets in one place 
2 Likes
Interview with Holden Oullette, the new maintainer of the Sobelow security scanner.
1 Like
In this post, I talk about using handle_call with noreply inside a GenServer, and how it may come in handy for certain situations, like transforming asynchronous requests into synchronous ones (there are a few catches of course, so be sure to read until the end).
I think you have a bug there. Generally, you need to keep a lookup table in the GenServer for all outstanding requests, keyed of an opaque token and pass the token down to the async process so you can figure which request is from which client and reply accordingly. You only have a field from_pid in the GenServer state, so concurrent clients are going to step on each other’s toe, the replies will get misdirected, and your clients will hang.
Hum, good point! But, I believe the answer is yes and no
In my use case (where I used this) I knew for sure that the given GenServer was unique per user currently active in a specific part of the Web App, as pointed out in the Things to take into account part. This means there could be only one different caller in that situation, so the need to store only one pid.
However, what you said is true if that isn’t the case, and the example code by itself can be a bit misleading. I updated the Things to take into account section to highlight this situation. (Timeouts, and other possible issues still need to be taken care of by the user).
Does it make sense and do you think it’s more clear now?
Thanks for the comment!
If your GenServer will not see concurrent usage, why go through all the trouble for deferred replies? You can just use a receive loop to wait from the response in the GenServer.
To be honest, I didn’t think of that when applying this to my initial situation, and a receive do feels like a better approach, even if for just readability purposes… Still, my main goal with this post was just to show that this was possible to do and that it can help in specific situations, as it’s something that may slip through when reading the docs, or just getting started.
