What is the right way to communicate between two GenServers?

[peerreynders]

@deerob4

it seems like a separate concern to the lobby

Have a read through the following topic and the related article: To spawn, or not to spawn?

Process and Stateness are they object?

Hey everyone, So I have been reading two elixir books Functional Web Development with Elixir, OTP, and Phoenix and Elixir in action. In the first book , it shows you how to hold state using Agents then later on changes the agents to GenServers. Now, I was starting to really understand what they were trying to convey, and the idea that kinda came up was that processes can be use kind of like objects to save your state. Now in Elixir in action, I don’t remember if it was the in book or in one of…

So, to summarize, in that post “thought concerns” refer to “I want to somehow organize a larger chunk of code, so it’s easier to work with”, while “runtime concerns” refer to “I want to get some observable runtime benefits, such as fault-tolerance, scalability, or potential for parallelism”.

Roughly (i.e. nothing is black and white):

• thought concerns → modules
• runtime concerns → processes

Also possibly:

Processes+messages VS Functional APIs - are they different?

Background Some time ago I read a huge post about pragmatic Dave and his components idea (along side with a healthy dose of his videos). His idea was that we should code a lot of small applications that communicate together instead of one big app. Having worked in a lot of monolithic projects (hello C#) this felt like an really good idea to me. Dave went ahead and even made a Components library: PragDave’s new Component library - his preferred way of building apps Erlangers The problem here,…

I like this idea, but would it still work if the Lobby process is restarted for some reason?

The server argument for cast can be a name - so require that as an argument for new_timer.

The bigger issue is, how would a restarted Lobby process re-aquire the previous state (which may have been responsible for the last process crashing in the first place)? If the state is lost then the timer is meaningless.

I’m also not sure how it’s different

Coupling is significantly reduced.

CountdownTimer.new_timer(completed_msg, time) lets the client choose the exact format of the message to be handled by its own handle_cast/2 callback. And CountdownTimer isn’t coupled to the client module - not even at runtime.