1. Yes this is true but Rails now comes with nice support for async UI built to push updates to the browser via Hotwire and Turbo.
You’d need something like that anyway anytime you’re calling an external service you don’t control.
2. Again this is also a good point but even running every request synchronously you still need good error logging because you don’t want to share details of an error with your frontend.
With background jobs you definitely need to be on top of monitoring and retry logic. I also think you need to be very careful about idempotency amd retry logic.
I see that as the engineering trade offs for that pattern. There’s very little in the way of silver bullets in engineering; different solutions just come with different trade offs.
1. Yes this is true but Rails now comes with nice support for async UI built to push updates to the browser via Hotwire and Turbo.
You’d need something like that anyway anytime you’re calling an external service you don’t control.
2. Again this is also a good point but even running every request synchronously you still need good error logging because you don’t want to share details of an error with your frontend.
With background jobs you definitely need to be on top of monitoring and retry logic. I also think you need to be very careful about idempotency amd retry logic.
I see that as the engineering trade offs for that pattern. There’s very little in the way of silver bullets in engineering; different solutions just come with different trade offs.