How to handle sideffects on GenServer or in General

I find this talk to be enlightening:

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.

Hey thanks that is perfect.

here is an example:

https://github.com/ityonemo/trivial/blob/master/lib/trivial/daemon.ex

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).