I’m working on a DockYard blog post idea and would like some input / examples from your experience.
Because it uses Cowboy, Phoenix spawns one cheap process per incoming request, and these are pre-emptively scheduled. This means that doing blocking work in one request doesn’t interfere with other requests, unlike in web frameworks where you have a limited number of server threads available. So the decision of whether to block vs use a background task is purely about user experience, not about keeping your site up.
Being able to block can let you do things more simply. Eg, import an uploaded CSV in a normal request cycle. Could be a background job, but doesn’t have to be.
It can also allow things that would be hard / impossible otherwise. Eg, in one project I know of, there are encrypted images in S3 that can’t be referenced directly from an <img> tag because the browser won’t be able to access them, so those image requests get proxied through Phoenix, which has access and can send down the unencrypted data. The client doesn’t even need to know the S3 bucket or key.
Have you seen other examples where being able to do blocking work in the request cycle is helpful?
I think you mean pre-emptively scheduled, otherwise blocking would be very bad indeed.
I have one API route that takes the user’s data and generates a big CSV file out of it. It can take a long time and be CPU intensive. I like that I don’t have to fork it out to a background task, but instead I can just handle it in the request directly. The client sets a longer timeout and shows a progress indicator for that route to take care of the user experience.
You have to be very careful with this. If you call a function from the controller action, and the user disconnects from the server while the function runs, the function will be interrupted. You should run long-running tasks under a different sueprvised process so that things keep working on the server even if the client disconnects. The Task module contains functions that help you do this and retrieve the result as if everything were aynchronous
@tmbb I relayed your point to @chrismccord and Jason Goldberger, and they pointed out that you could async_nolink a task and block the controller response until you got a result; that doesn’t have the simplicity of “just do it inline”, but it does mean that for the client, getting the response is as simple as “request and wait for the response”.
Can’t seem to edit it now, though.
