3 ms·
> that's still less elegant than simply performing those requests inline and not having to worry about all the additional moving parts that the jobs entail. I
by byroot 4y ago
> that's still less elegant than simply performing those requests inline and not having to worry about all the additional moving parts that the jobs entail.
I strongly disagree here. Going through a persisted queue gives you lot of tools to manage that queuing.
If you were to just spawn a goroutine or some similar async construct you lose persistence, lots of control on retries, resiliency by isolation etc. When you have "in process jobs" re-deploying the service become a nightmare as it becomes extremely muddy how long a request can legitimately take.
Whereas if you properly defer these slow IOs to a queue, and only allow fast transactional request, you can then have a very strict request timeout which is really key for reliability of the service.
- notpachet 4y agoThose are all fair points. My only counterargument is that for a certain class of requests, the simplicity of not needing to worry about a separate background jobs queue outweighs the benefits that the job queue provides. There's some fuzzy line where those benefits become worth it. And you're probably going to cross that line earlier with a Rails app than with an evented one. There are lots of cases in Rails where problems are solved via background jobs that would most likely just stay in the parent web request in an IO-friendlier environment.