Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rack.after_reply #169

Closed
tleish opened this issue Apr 14, 2022 · 1 comment
Closed

rack.after_reply #169

tleish opened this issue Apr 14, 2022 · 1 comment

Comments

@tleish
Copy link

tleish commented Apr 14, 2022

Does falcon support something similar to env["rack.after_reply"].

See also: Performance at GitHub: deferring stats with rack.after_reply | The GitHub Blog

@ioquatix
Copy link
Member

ioquatix commented Apr 15, 2022

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:

  • 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.

@socketry socketry locked and limited conversation to collaborators Apr 15, 2022
@ioquatix ioquatix converted this issue into discussion #170 Apr 15, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants