ioquatix
commented
2 years ago We are looking to standardise the behaviour: https://github.com/rack/rack/pull/1802 - once it's done I'll implement support for the SPEC.
In any case, there are better ways to deal with this kind of issue:
- Background thread with work queue & batching.
- Async task + batching (probably best approach).
Most use cases for after_reply are simply better handled with background batch processing IMHO. Not only would it be more responsive, it won't stall other request handling which conceivably with persistent connections on HTTP, it will if it's executed on the same thread.
If we do end up supporting "after_reply" or whatever ends up in the SPEC, we might not do it in the same request handler because it's bad for performance. If you are using "after_reply" to submit data via say, HTTP, you'd block subsequent requests, we might transparently batch it into a background queue.
Does falcon support something similar to env["rack.after_reply"].
See also: Performance at GitHub: deferring stats with rack.after_reply | The GitHub Blog