-
Notifications
You must be signed in to change notification settings - Fork 848
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
feat(plugin-http): add plugin hooks before processing req and res #963
Merged
+101
−1
Merged
Changes from 2 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
b348ec7
feat(plugin-http): add plugin hooks before processing req and res
blumamir 8e8d753
fix(http-plugin): response hook bind to right plugin instance
blumamir d49c563
perf(plugin-http): remove function calls when no hooks are configured
blumamir 6fdc120
Merge branch 'master' into req-res-hooks
blumamir 51151df
style(plugin-http): lint fix
blumamir 64e9def
Merge branch 'master' into req-res-hooks
dyladan 3841e1c
Merge branch 'master' into req-res-hooks
mayurkale22 4219db8
Merge branch 'master' into req-res-hooks
dyladan File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that probably it would be better if you modify this whole concept a bit because of performance issues.
First Approach
During a plugin initialisation check if user defined a hooks in config if that is the case then add simply a different event listener (request.on) with your modifications
plugin._onNewRequest
etc. otherwise use the one without your modifications.This will have some code duplication but in fact 0 performance issue if user doesn't define any hooks.
Second Approach
Also during initialisation check if user defined a hooks in config but this time add separate event listener and then call
plugin._onNewRequest
.This could be achieved by adding extra parameter to
_traceClientRequest
.This would be basically a callback for setting up the desired events, but if user doesn't define the hooks this callback will be simply something like
NoopHookCallback
which will look likefunction () {}
and can be called before returning the request inside function_traceClientRequest
WDYT ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review,
Regarding the performance impact, when these function are not set, the only performance issue is function call to
_onNewRequest
\_onNewResponse
, and executing an if:if (this._config.requestHook)
. Is it something to worry about?On plugin initialisation I still have no
request
`responseobjects on which I can add events. I call the function to register events as soon as the
request` object is available (in incoming or outgoing functions).What I can do is to register on the
http.Server
request
Event, but then I'll get a callback without the relevant span, and it will be called every-time, also when the request is ignored in open telemetry.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. When this is done on every single request and response on both client and server it is something to worry about. Function call overhead is non-negligible. Right now you have a function which is called every time and an if-check that happens inside the function. Moving the if-check outside of the function and only calling it if there is something configured would be drastically more performant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @dyladan
I wasn't aware of the impact of the function call. Will perform the if-check before calling the function and push a new commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the change you did will have exactly the same number of checks then previously
is exactly the same as
What I tried to say is to refactor into something like this
this way you will have some duplication in code, but when it is about performance, you will check only once for
config.c
rather then every time onsome event
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, missed the comment.
I like the idea of registering to the
EventEmitter
interface.In this case, the hook is exposing the
request
object (which we get as the patched function parameter) so the user is able to do function calls likerequest.on('some event', a1);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be more precise, the above code still execute the
if (config.c)
per request which is the same as what current implementation is doing