I hope I am asking the question the right way here.
I’m curious as to the benefits of introducing additional GenServer usage for internal state management within an API build around phoenix framework. Does it offer any additional benefits over validating state using database constraints?
I see concurrency and fault tollerance mentioned with GenServers too, but doesn’t Phoenix already take care of this?
An example scenario:
I am a student.
I want to be able to create a study groups.
I want to make sure that a student can only be in one study group per subject they study
I want to be able to invite other students to the group I have created
All this to me, can be locked down at the database layer and the only thing I see the GenServer introducing is a bottleneck that all my group related actions have to go through.
And if I wanted to scale the app, it behaves the same. The database still manages concurrency and validation.
Is there something I am missing with this here?
edit: ah hell, something just dawned on me. If I want to allow multiple people to add people to the group in the future I am going to have issues aren’t I?
Yes and no, they use case is completely different. GenServers are useful in cases where you need failure isolation.
Not Phoenix, but Cowboy which is underlying HTTP and WebSocket server.
If you use GenServer incorrectly it will be and bottleneck, but it has it’s use cases. For example imagine that you want to do background processing of data in a pool. Then you can use pool like poolboy and then each GenServer process will be responsible for one task. Other use case is when you want to provide simple cron-like features. Or you want to handle custom startup-shutdown features (for example connection draining). And so on. There is a lot of possible use cases outside of the REST-like HTTP connection handling.
You’re not missing something. If you have a db it’s totally fine to protect invariants in the db. But there are cases where you don’t want to use the db (ephemeral data) or the db doesn’t scale well enough, so you e.g. shard access in the app layer. Those are the ones where additional processes can be quite useful. E.g. a few days ago I use a GenServer to act as a room for people to join via phoenix channels, which does only disappear after a certain timeout of nobody being connected. Sure I could’ve modeled this by putting information in the db and on channel connects see if the room is in the db and some “cron” like job to cleanup the db records after timeout, but it was way simpler to model as processes.
Are you saying, that if there is an error at the minute, it will take down anything that phoenix is currently doing? If this is isolated to the process, what are the drawbacks to it just taking down an active HTTP request where are the drawbacks if all I would be doing is handling that error and abandoning the GenServer.call anyway?
Building on what @LostKobrakai said - the best fit I’ve found so far for GenServers is for actions that need to happen spread out over time. (FWIW, the apps I work on haven’t reached the kind of scale that makes Postgres blink so I can’t speak to scaling advantages)
For instance, we use GenServers at work to track orders that are awaiting pickup by a courier and alert our support team if the pickup is late. In other languages, this might be done with a work queue / scheduler (think Resque / Sidekiq / etc) with a bunch of accounting to cancel the future job when the pickup happens. Using a GenServer (by way of GenStateMachine) makes the logic match the problem description, by using a state_timeout and transitioning on pickup.
Thanks for the use case, it is quite an interesting one and makes sense.
This is pretty persistent data that shouldn’t change often, maybe every semester.
But, now I’ve had thought about, what if I allow members of the group to invite or add more students to the group in the future. I’m going to hit issues there. So it feels like I might need a GenServer later on if I make changes. I’m considering an upsert for now though.
But if I do end up having to spin up a GenServer per group, your implementation of having them time out if no one has updated them in the last while sounds pretty useful. I am not sure of the cost of burning and re-creating processes though VS maintaining a process for every group that is created.
