-
|
Does falcon support something similar to env["rack.after_reply"]. See also: Performance at GitHub: deferring stats with rack.after_reply | The GitHub Blog |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
We are looking to standardise the behaviour: rack/rack#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:
Most use cases for 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. |
Beta Was this translation helpful? Give feedback.
We are looking to standardise the behaviour: rack/rack#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:
Most use cases for
after_replyare 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 perfo…