Creating Named GenServers in Elixir Using Registry

Guilherme Bordallo — Tue, 10 Dec 2024 18:51:35 +0000

In this guide, we’ll explore how to use Registry along with a Dynamic Supervisor to create named GenServers.

Let's start by creating a simple GenServer

defmodule Server do
  use GenServer

  def start_link({init_arg, name}) do
    GenServer.start_link(__MODULE__, init_arg, name: name)
  end

  @impl true
  def init(arg) do
    {:ok, arg}
  end

  def state(name) do
    GenServer.call(name, :state)
  end

  @impl true
  def handle_call(:state, _from, state) do
    {:reply, state, state}
  end
end

{:module, Server, <<70, 79, 82, 49, 0, 0, 19, ...>>, {:handle_call, 3}}

Now, we can start a new instance of the GenServer and attempt to retrieve its current state.

initial_value = 123
server_name = :server
Server.start_link({initial_value, server_name})

{:ok, #PID<0.160.0>}

Server.state(:server)

Note that the name cannot be a string:

Server.start_link({123, "server"})

Dynamic Supervisor

With our GenServer ready, the next step is to create a Dynamic Supervisor that will manage and start our GenServers.

defmodule DSupervisor do
  use DynamicSupervisor

  def start_link(init_arg) do
    DynamicSupervisor.start_link(__MODULE__, init_arg, name: __MODULE__)
  end

  def init(_init_arg) do
    DynamicSupervisor.init(strategy: :one_for_one)
  end

  def start_server(initial_value, name) do    
    DynamicSupervisor.start_child(__MODULE__, {Server, {initial_value, name}})
  end
end

{:module, DSupervisor, <<70, 79, 82, 49, 0, 0, 10, ...>>, {:start_server, 2}}

Now, we can start the Dynamic Supervisor and use it to launch another GenServer.

DSupervisor.start_link(1)

{:ok, #PID<0.170.0>}

DSupervisor.start_server(321, :test)

{:ok, #PID<0.171.0>}

Server.state(:server) |> IO.inspect()
Server.state(:test)

So, what’s the issue?

Naming a GenServer using atoms is generally not a problem. However, if your application dynamically creates GenServers with different names—such as when users start GenServers by creating a new match in a browser game or starting a new chat room—this approach can lead to problems.

Atoms are not garbage collected, and dynamically generating them as names for GenServers increases memory usage over time. Eventually, this can exhaust the atom table and cause the application to fail.

To solve this, we need a way to associate a custom name with a GenServer while storing its PID. Fortunately, Elixir provides a built-in solution for this: the Registry.

Registry.start_link(keys: :unique, name: Registry)

{:ok, #PID<0.172.0>}

Now we can use the Registry to register process names.

name = {:via, Registry, {Registry, "cool_name"}}
DSupervisor.start_server(42, name)

{:ok, #PID<0.174.0>}

Server.state(name)

The Registry allows us to fetch the PID of a process using the lookup function, which we will use in this guide to terminate a server.

[{pid, _value}] = Registry.lookup(Registry, "cool_name")
 DynamicSupervisor.terminate_child(DSupervisor, pid)

:ok

Registry will monitor the GenServer and automatically remove the registration when the GenServer is terminated.

Server.state(name)

By using the Registry, we can safely register and manage names for GenServers with ease, ensuring that each process is uniquely identifiable and accessible. The Registry also helps by automatically cleaning up registrations when a GenServer is terminated, preventing memory leaks and improving the efficiency of your application.

With this approach, you can build scalable, maintainable systems where users can dynamically create and interact with multiple GenServers without worrying about the limitations of atom-based naming.

A few noteworthy details

When starting the Registry or the Dynamic Supervisor, the name we use sometimes looks like a module, but they are just atoms, they could be named differently, like :registry or :supervisor

Registry.start_link(keys: :unique, name: :registry)
name = {:via, Registry, {:registry, "another_name"}}
DSupervisor.start_server(42, name)

{:ok, #PID<0.5230.0>}

Interacting with the Registry could be encapsulated within the GenServer, making it easier to work with.


defp registry_name(name), do: {:via, Registry, {:registry, name}}

def start_link({init_arg, name}) do
  GenServer.start_link(__MODULE__, init_arg, name: registry_name(name))
end

def state(name) do
  GenServer.call(registry_name(name), :state)
end

Git's Hidden Gems: How to Stage Selective Changes with --patch flag

Guilherme Bordallo — Wed, 28 Feb 2024 03:51:20 +0000

Git is a potent tool, and even working with it for a few years, I end up learning something new from time to time.

TLDR;

Running git add with --patch or -p will make git split the file changes into several hunks, display each hunk, and ask you to do with that hunk, most of the time you will choose between y or n which means stage or not.

The Problem
You see yourself in a scenario where you have two or more changes in the same file, and for some reason, you believe it would be better to split those changes into different commits. I usually do that to organize the commits in a way that makes it easier for the reviewers to read the changes.

Let's check how to do it in a very simple example:

Here's part of a package.json we are going to use as an example:

{
  "description": "A frontend for Home Assistant",
  "repository": {
    "type": "git",
    "url": "https://github.com/home-assistant/frontend"
  },
  "name": "home-assistant-frontend",
  "version": "1.0.0",
  "scripts": {
    "build": "script/build_frontend",
      ... 
     "test": "instant-mocha --webpack-config ./test/webpack.config.js --require ./test/setup.cjs \"test/**/*.ts\"",
  },
  "author": "Paulus Schoutsen <Paulus@PaulusSchoutsen.nl> (http://paulusschoutsen.nl)",
  "license": "Apache-2.0",
  "type": "module",
  "dependencies": {
    "@babel/runtime": "7.23.9",
    ...
  },
  "devDependencies": {
    "@babel/core": "7.23.9",
    ...
  },
  "_comment": "Polymer 3.2 contained a bug, fixed in https://github.com/Polymer/polymer/pull/5569, add as patch",
  "resolutions": {
    "@polymer/polymer": "patch:@polymer/polymer@3.5.1#./.yarn/patches/@polymer/polymer/pr-5569.patch",
    "@material/mwc-button@^0.25.3": "^0.27.0",
    ...
  },
  "packageManager": "yarn@4.1.0"
}

Let's say you had to add a new dependency to help you build a new feature:

"dependencies": {
    "@babel/runtime": "7.23.9",
    ...
    "@new/dependency": "1.0.2"
  },

While testing, you realized that there was a flag missing in the scripts, so you also added it:

 "scripts": {
   ...
   "test": "instant-mocha --missing-flag --webpack-config ./test/webpack.config.js --require ./test/setup.cjs \"test/**/*.ts\"",
}

You have finished implementing the feature and are now ready to commit. Running git add -p package.json will display one of the changes and ask what you want to do with this change:

There are a few options ([y,n,q,a,d,j,J,g,/,e,?]) But usually, you will choose between y (yes) or (no)

After choosing what to do, it will display the next change and repeat the question:

In the example, we are saying to Git to stage the first change but skip the second one.

Now we can commit the first change then stage the next change and commit it as well.
Each change with the message that fits it best.

Thank you for reading!

DEV Community: Guilherme Bordallo

Creating Named GenServers in Elixir Using Registry

Dynamic Supervisor

So, what’s the issue?

A few noteworthy details

Git's Hidden Gems: How to Stage Selective Changes with --patch flag