You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sanic allows adding user data to app and request objects (latter via request.ctx after #1666 got merged). Additionally, per-connection (across requests in HTTP pipelining) data could be added too, and be useful e.g. for middlewares implementing user tracking or slightly more sophisticated request rate limiting.
According to our current test suite, app middleware would add their things directly as app member variables, although I am not aware of middlewares or other software actually making use of this. Adding directly to Sanic core objects is problematic, as any future additions to the Sanic object will need to consider name collisions with any existing software.
Therefore, I am suggesting to add app.ctx and possibly request.transport.ctx (or something alike) for holding these data in the same manner as the per-request request.ctx.
It needs to be noted that app object is duplicated in each worker, and thus changes when the server is running would only affect that particular worker. Furthermore, any data added before the server forks will in general need to be picklable, although I'd like to change this so that all initialization, including that of user's main module and app definition, would be done locally in each worker instead of passing from main process by pickling/forking.
Are you aware of any such use or need for it, or care to share any other thoughts on this matter?
The text was updated successfully, but these errors were encountered:
Tronic
changed the title
User context in app, connection and request
[RFC] User context in app, connection and request
Sep 26, 2019
If running multiple workers in a context like this, I would suggest against an implementation like this and advise to use something outside of Sanic to share between the processes.
With that said, I have not put any thought into this, nor do I have any strong formulated opinions on whether this is something that would/should be a part of Sanic. For example, how would that work when using an ASGI server?
@seemethere Apparently you wrote the test for this in test_request_data.py test_app_injection. Do you happen to recall what that was for, or if anyone is using app object for external data?
If no-one is using it, this issue should be closed and probably that test also removed.
I spent some time playing around with this and it is not a difficult add. My biggest concern would be out of the box performance issues when it is not required, particularly on connection based context. Although, the idea is certainly well warranted as it could overall help app developers to speed up their apps by skipping steps on subsequent calls.
I am going to add this to 21.6 for now, but if anyone grabs it and wants to get it done sooner we can bump it up. Ping me if you start to work on this and I will share my thoughts.
Sanic allows adding user data to app and request objects (latter via
request.ctx
after #1666 got merged). Additionally, per-connection (across requests in HTTP pipelining) data could be added too, and be useful e.g. for middlewares implementing user tracking or slightly more sophisticated request rate limiting.According to our current test suite, app middleware would add their things directly as app member variables, although I am not aware of middlewares or other software actually making use of this. Adding directly to Sanic core objects is problematic, as any future additions to the Sanic object will need to consider name collisions with any existing software.
Therefore, I am suggesting to add
app.ctx
and possiblyrequest.transport.ctx
(or something alike) for holding these data in the same manner as the per-requestrequest.ctx
.It needs to be noted that
app
object is duplicated in each worker, and thus changes when the server is running would only affect that particular worker. Furthermore, any data added before the server forks will in general need to be picklable, although I'd like to change this so that all initialization, including that of user's main module and app definition, would be done locally in each worker instead of passing from main process by pickling/forking.Are you aware of any such use or need for it, or care to share any other thoughts on this matter?
The text was updated successfully, but these errors were encountered: