How to handle sideffects on GenServer or in General

JeancarloBarrios · February 13, 2020, 5:11am

I’m just wondering if there is a specific pattern I have to follow to handle side effects of any type in a GenServer or any OTP Behavior like API calls, database calls, etc. Or even if I should keep the functions pure or not?

ityonemo · February 13, 2020, 8:07am

I find this talk to be enlightening:

https://www.destroyallsoftware.com/talks/boundaries

However, there is no easy answer, and I think this is ultimately one factor that separates a seasoned senior developer from the rest.

I have a few rules that I personally use:. I group API functions together usually near the top. Calls are short, and directly below I have *_impl equivalents which occur inside the gen_server. Internal tasks run by the server loop are named do_*. I put almost nothing in the handle_* functions, and label them as “router” in a comment, analogously to a phoenix or rails router. Usually the handlers I hide away, and I make the impls they call consistent so you never have to look at that section.

JeancarloBarrios · February 14, 2020, 6:50pm

Hey thanks that is perfect.

ityonemo · February 15, 2020, 3:14am

here is an example:

github.com

ityonemo/trivial/blob/master/lib/trivial/daemon.ex

defmodule Trivial.Daemon do
  @moduledoc """
  UDP Daemon for the TFTP protocol.  Listens on a port for "accept"-style UDP
  connections, then spawns a server to handle the continued processing of the
  results.

  You should use this module directly to start up a TFTP service if you don't
  necessarily want a supervision tree, for example, in tests.  The daemon and
  server processes, will still be linked, so an error will bring down the
  entire Daemon instance.

  ## Example

  The following code starts up a TFTP service on a free udp port and
  retrieves the udp port so that you can run tests against the functionality
  of MyModule:

  ```
  {:ok, daemon} = Trivial.Daemon.start_link(MyModule, initial_value, port: 0)
  dest_port = Trivial.Daemon.port(daemon)

This file has been truncated. show original

bootstrapping boilerplate grouped at the top,

API section with comment fence in the middle, each function grouped with its implementation
Some indirect API functions that are not "do_"s because they are called externally when the system sends a message.

(no do_'s in this particular module), that’s because I forgot to label “start_server” as “do_start_server”.

router on the bottom. Ideally, you should rarely if ever have to examine the router code once written.

Also, if I have a server (genserver or state machine) that has very complex state requirements (aka, not a single scalar or simple list) I prefer to have the internal kept datastructure a struct, and usually I declare typing info on it too.

Last rule is, if you don’t really need state, don’t use it. I only use genservers and gen_statems/state_server when I absolutely have to model the state of something IRL, or some sort of stateful communication protocol. For everything else there’s Tasks, (or it’s linear, functional, stateless code running in “someone else’s” process, like a liveview for example).