-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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: allows users to specify plugin execution priority #7273
Conversation
```json | ||
{ | ||
"serverless-post-function": { | ||
"_meta": { |
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.
As I already mentioned, this is poor Developer Experience. It makes the use of the configuration more complex for no reason except that it's easier to implement.
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 also think priority
should not be in _meta
, it doesn't fit the definition of _meta
, it only works for plugin bound objects. How about a custom priority directly as a base property of the plugin? ref: #6580 (comment)
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.
The plugin property will affect every plugin configuration, not just what we configure for.
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.
After discussing with @spacewander , I changed my mind.
_meta
is based on the concept of abstraction of all plugin configurations, which are available to all plugins. So to distinguish it, it should have a separate configuration field, i.e. _meta
.
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, but again, you speak from an engineering perspective. I'm talking from a user perspective. As a user, it's not fundamental whether the configuration parameter can be used across multiple plugins.
Here, I need to know and remember:
- The parameter name, i.e.,
priority
- The parent's name, i.e.,
meta
- The prefix, i.e.,
_
Only #1 is mandatory. You make #2 and #3 necessary and impair the ease of use for engineering reasons. While I understand there's a tension between the ease of implementation and ease of use, I don't see any good reason to force those additional requirements onto users at this point.
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, it is most directly to make priority
one of the properties of the plugin. just like disable
, what your option? @spacewander
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.
No. Setting the new field directly on the configuration may override people's current configuration. We should avoid break change
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 have submitted a PR to explain it in the comment: #7290
} | ||
``` | ||
|
||
The default priority of serverless-pre-function is 10000, and the default priority of serverless-post-function is -2000. By default, the serverless-pre-function plugin will be executed first, and serverless-post-function plugin will be executed next. |
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.
At this point, why do we keep two different functions? We can keep a single one as call it whenever we required it. Can we change the sample?
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.
A good use-case would be the combination of proxy-mirror
plugin and the proxy-rewrite
one.
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.
A good use-case would be the combination of
proxy-mirror
plugin and theproxy-rewrite
one.
I tried it and the two plugins don't show well to work together by customizing the priority.
Maybe you're talking about changing the request path via the proxy-rewrite
plugin, and then proxy-mirror
using that new path.
But proxy-rewrite
plugin update uri on the var ctx.var.upstream_uri
, but proxy-mirror
get the uri by the var ctx.var.uri
, this is the difference in implementation.
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 tried it and the two plugins don't show well to work together by customizing the priority.
That's actually the origin of my initial requirement.
Maybe you're talking about changing the request path via the proxy-rewrite plugin, and then proxy-mirror using that new path.
Indeed!
Imagine that I receive a request for v1/hello
. Now, my requirements are:
- The prefix
v1
to be removed - The request to be forwarded to the upstream
- The request to be duplicated to the mirror
But proxy-rewrite plugin update uri on the var ctx.var.upstream_uri, but proxy-mirror get the uri by the var ctx.var.uri, this is the difference in implementation.
Again, how are users supposed to know this? It's an implementation detail.
The requirements make sense from a functional point of view.
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.
Since proxy-mirror
support rewrite path
, so we can implement the above requirements, but we just need to configure them separately on proxy-mirror
and proxy-rewrite
.
Of course, we can also modify the proxy-mirror
plugin to read the ctx.var.upstream_uri
variable. But it won't be done in this PR.
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.
we can also modify the proxy-mirror plugin to read the ctx.var.upstream_uri variable
in this way, we can match the requirements
Description
Fixes #6580
Fixes #7248
Checklist