Work that outlives a request
Why "just do it in the request" stops working, and what the alternative looks like.
A user clicks a button and waits. Everything you do before responding is time they spend staring at a spinner. Sending an email takes a second. Generating a report takes thirty. Processing an uploaded video takes ten minutes. At some point along that scale, making the user wait stops being acceptable and starts being impossible.
- Accept
Write down that the work needs doing. This is fast. - Respond
Tell the user it is underway. They get on with their life. - Process
Something else picks the work up and does it. - Notify
When it finishes, tell the user: email, notification, or a status they can poll.
This changes what your interface has to say. "Done" becomes "started", and you now need somewhere to show progress and somewhere to show failure. That extra surface area is the real cost of background work, and it is why you should only move work out of the request when you have to.
What to remember
- Long work inside a request gets killed, not just resented.
- Accept the work, respond immediately, process elsewhere, report back.
- Backgrounding work adds progress and failure states to your UI.
Terms in this lesson
Show field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.