-
Notifications
You must be signed in to change notification settings - Fork 339
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
Rewrite API for hooking into requests and responses. #136
Comments
One way of modifying requests and or responses is to wrap to apply a decorator to a handler. Consider the following decorator that measures the execution time of handlers: def time_it(f):
def inner(*arg, **kwargs):
start = time.time()
resp = f(*args, **kwargs)
delta = int((time.time() - start) * 1000)
print("Handler took {delta} ms to execute")
return resp
return inner It could be used like this: class ChargePoint:
@on("Heartbeat")
@time_it
def on_heartbeat(self, *args, **kwargs):
pass Note that this implementation of Applying the decorator above has drawbacks. One might send another Using a decorator allows to implement middleware for individual routes. But what if you want to apply some logic to all incoming requests? Applying the same decorator to all handlers is cumbersome. One could apply a decorator to |
This issue is stale because it has been open for 30 days with no activity. |
This issue was closed because it has been inactive for 14 days since being marked as stale. |
Currently this package provides 2 ways of routing calls:
@on()
- Main handler for a call. It's response is send back as a other end of the connection.@after()
- Optional handler that is executed after the@on()
is executed. It receives same arguments as@on()
but its response is discarded.The current options for routing are limited and have problems.
First the problems:
@after()
handlers are not executed if the in corresponding@on()
handler an exceptions is raised. This behavior is not clear from API.@after()
handlers require a corresponding@on()
handler, otherwise they never will be executed. Again this is an unclear, implicit relation between the@on()
and the@after()
handler.@after()
can't be catched.@after()
handlers are 'fired and forgotten' because the coroutines are started usingasyncio.ensure_future
. This could lead to long running tasks in the background without that a user knows that.Now the limitations:
@on()
handler. Nor it's possible to access the response before it's put on the wire.Here some use cases that aren't possible because of the current problems:
A) Logging requests and responses to a different place than stdout. For example at the Mobility House we want to store certain requests in a database. That isn't possible without relying on internals of
ChargePoint
.B)Tracking the execution time of a
@on()
handler.C) Catch exceptions raised in an
@on()
handler.I think the
@on()
is working fine. But we need to change the API to allow users to hook into requests and responses before and after the@on()
handler.The text was updated successfully, but these errors were encountered: