fabioticconi
Command Pattern via TCP
Hi all, I come from a relatively brief Erlang background from many years ago, and I’m trying now to think (again) in that distributed way - while learning Elixir, which I prefer at a glance.
In short, I’d like to know what (if any) is the Elixir-way to deal with a pattern I encounter often my side projects: the command pattern.
Assume I have a little TCP server setup (via ranch, in fact) and I want to have a clean way of adding commands to manipulate “global state” (currently, I’m using Mnesia… but I already feel like this is not well supported in Elixir. A question for another day).
I went the polymorphism way, so each command is a module with behaviour Command which, in itself, defines callbacks. A series of processes run these commands.
However, clearly each string coming from the socket needs to be processed and validated as a Command. This is my attempt:
defp parse!(_, ["quit" | _]) do {:ok, :quit} end
defp parse!(_, ["shutdown" | _]) do {:ok, :shutdown} end
defp parse!(_, ["echo" | opts]) do {:ok, {:echo, Enum.join(opts, " ")}} end
defp parse!(_, cmd) when cmd == [] do {:ok, {:echo, ""}} end
defp parse!(_state, [cmd | opts]) do
module_name = Macro.camelize(cmd)
try do
module = String.to_existing_atom("Elixir.Commands.#{module_name}")
{:ok, {module, opts}}
rescue
_ -> {:ok, {:echo, "#{cmd}: UNKNOWN_COMMAND"}}
end
end
It works, but I think it’s very brittle. So I’m trying meta-magic but I’m not sure I’m going in the right/sensible/idiomatic direction:
defmacro __using__(_opts) do
quote do
@behaviour Command
@on_load :register_command
def register_command() do
Command.register_command(__MODULE__)
end
end
end
This essentially allows me to register a command implementation, when it’s loaded. Again, it works, but I’m not sure it’s the right way.
If you can advise or point me in the right direction, I’d be very grateful
Elixir is a very interesting language and I’d love to continue working with it.
Marked As Solved
al2o3cr
Consider the simplest thing that could work: listing the mapping from command to handler atom explicitly.
@handlers %{
"foo" => Commands.Foo,
"bar" => Commands.Bar,
# etc
}
defp parse!(_state, [cmd | opts]) do
case Map.fetch(@handlers, cmd) do
{:ok, mod} -> {:ok, {mod, opts}}
:error -> {:ok, {:echo, "#{cmd}: UNKNOWN_COMMAND"}}
end
end
This approach also has logical extension points for useful things:
- broadening the possible keys of the map to things like
Regexes would allow for “partial match” commands - broadening the possible values of the map to
{module, baked_in_opts}lets one “command module” serve multiple external commands
One downside is that the command → module mapping can get quite long; consider extracting parts of it to functions and combining them at compile-time to reduce clutter.
Worth looking into persistent_term for storing the map - an Agent still forces every access through a single thread.
Also Liked
ityonemo
For the level of dynamicity you seek, the on_load idea is correct.
For idiomacity:. I recommend not doing shenanigans with camelize and string.to_atom. instead, I recommend registering your modules by updating an application env value (this is backed by an ets table, so it is blazing fast). The keys should be stringified final term of Module.split and the value should be the module itself.
Nitpicky: parse should not be parse!
ityonemo
Use application.put_env and application.get_env instead of an agent, it doesn’t need to be supervised, you don’t have to worry about it going down, etc.
Functions that end in ! by convention signify that they are a raising equivalent of a function that emits ok/error tuples
ityonemo
Looks like I was subtly wrong about ! convention:
https://hexdocs.pm/elixir/1.12/naming-conventions.html
But I would also say “don’t put a ! just because something can error”; I would say non-bang functions can raise on “programmer fault” (something analogous to :badarg); but should not raise on “user fault”.







