> One of the strengths of GenServers is that they allow us to spin one up per user very easily, so they don't become a bottleneck where the Agent does.
Agent is a special case of GenServer[1]. With the same luck we could spin up an agent per user.
In addition to what the offer recommended in the "Scheduling work" section, using the `:timer.send_interval()` can be useful if you want to do something every X seconds, instead of every X + Y seconds, where Y is the time it takes to process the "work" message.
Also I prefer to use `handle_continue` instead of `schedule_work()` style (which in a lot of cases pre-date the introduction of `handle_continue`).
Having reliable scheduling in the language itself seems like it would simplify a ton of software that's currently reliant on a lot of message queueing and cron duct tape. Running BEAM in production still scares me, but that's one reason to conquer the fear.
Makes sense. For what it’s worth we’ve been really happy with traces, no issues there, and there are definitely profiling tools. Plus you can point Erlang’s Observer tool at a production BEAM node, it’s wildly useful!
10 comments
[ 1.7 ms ] story [ 30.8 ms ] threadAgent is a special case of GenServer[1]. With the same luck we could spin up an agent per user.
[1] [Agent.start_link/2](https://github.com/elixir-lang/elixir/blob/9137fd1cb2368bb1b...)
The ability to add cache annotations to functions feels really clean.
There’s also the ability to have cluster wide state but we haven’t set that up yet. We will soon.
It also seems a clean way to fill the lack of integrated cache solution in ecto.
Also I prefer to use `handle_continue` instead of `schedule_work()` style (which in a lot of cases pre-date the introduction of `handle_continue`).
Also I want to comment that it is awesome and I love it. It’s simple and effective. OTP being bundled into the language is really very brilliant.