A minor addition to Erlang/OTP 21 that could make life a little easier
For the past few years, I’ve been heavily leveraging GenServer behaviours that advance themselves across various internal states using a pattern of
handle_info/2 callbacks. Why? Because I’ve found this approach makes it really easy to do complex things at scale when combined with something like the
GenStage.ConsumerSupervisor behavior. By having each GenServer process handle it’s own progression at it’s own rate — combined with back-pressure capabilities GenStage provides, I find my systems to be much more balanced and predictable in regards to load.
For the sake of this example, let us leave GenStage out of this for now and focus on an example using a GenServer that adds food items to it’s own internal state as a series of messages sent and handled by it’s own callbacks. …
GenServer.call is not just for returning a response
I have been working on a side project using Elixir with a friend who is new to the language. He has some functional programming experience, but none using the Erlang/Elixir actor model. It was tricky at times to explain the fact that a single actor in this world can do only one thing at a given time even though you often hear about the BEAM VM and its abilities to handle concurrency. The reality is that multiple actors are often needed to get things done.
One of the new additions in Elixir 1.4 that I’ve been looking forward to is the new Registry module. Let’s look at one way to take advantage of this handy feature that is now part of the core library.
Github Example - https://github.com/amokan/registry_sample
If you are new to Elixir and learning the basics of OTP, especially while using the REPL (iex), you may find yourself overwhelmed with the abundance of process IDs or PIDs you end up keeping track of. With the actor model, it is not uncommon to have hundreds or thousands of processes running in a system. Some ways we reference these processes are by keeping track of a PID or by a specified name when we launch a process. …
UPDATE (2016–09–29): The following approach should not be used due to the fact that it will cause more demand to be triggered while your work is being done asynchronously. A DynamicSupervisor can be used to limit concurrency and act as a GenStage consumer. See the detailed response from José Valim.
I apologize to anyone who followed this path, as I was just really excited that it ‘functioned’ without resorting to the manual subscription mode, but that perceived functionality comes at a cost. …