nathanl
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?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Nicd
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.
nathanl
Yes, that was what I meant.
Can’t seem to edit it now, though.
tmbb
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
nathanl
That’s an extremely good point, thank you.
nathanl
@tmbb I relayed your point to @chrismccord and Jason Goldberger, and they pointed out that you could
async_nolinka 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”.tmbb
That solution is exactly what I use