[suggestion] plug-in flexibility

[solo-xwz]

1. 比如一个插件A，应用到全局之后，如果想对某个用户单独设置不同配置的插件A，结果该用户调用的时候，全局和用户下的插件A都会执行，就很尴尬，按一般的逻辑，全局插件应该是优先级最低，最后兜底的吧
2. 插件绑定对象不能灵活组合，比如绑定到用户下的插件不能针对不同的服务或路由设置规则
3. 新增或修改consumer下的插件，都得PUT全部提交一遍，新增还好，如果想单独修改下某个插件配置，就很麻烦，plugin id也没有
4. 还有个疑问，dashboard为啥直接对接etcd不对接Admin API？

插件这块，感觉还是Kong比较好用，可以自由地应用到不同的route、service、consumer组合上，都不应用就是全局的，插件开发文档也差很远，很多要自己看源码才明白

本来想从kong尝试转apisix，但是插件还是不习惯，不知道是不是使用姿势不对，如有不正请指教，希望国产开源越来越好，忍不住吐槽下

[juzhiyuan]

Hi @solo-xwz, thanks for your feedback anyway.

新增或修改consumer下的插件，都得PUT全部提交一遍，新增还好，如果想单独修改下某个插件配置，就很麻烦，plugin id也没有

Apache APISIX is using ETCD as config center, and ETCD is Key/Value, so we don't have something IDs to build relations AFAIK. For now, we could use the Dashboard or plugin_name to update one Consumer. May I know more information about your scenarios? I'd like to know exactly what confuses you when updating Consumer.

还有个疑问，dashboard为啥直接对接etcd不对接Admin API？

It depends on the Dashboard's architecture, in months ago, our community wants to use ManagerAPI instead of AdminAPI totally, so apache/apisix is a pure Data Plane, but we haven't achieved this goal. That's why we have both AdminAPI and ManagerAPI now. Personally, I'm planning the new Dashboard (let's call it V3), once I finish the proposal, I will send it to our mailing list and invite everyone to review it. In my proposal, I would suggest using AdminAPI to operate resources and let the Dashboard is a pure Web project.

插件开发文档也差很远，很多要自己看源码才明白

You're right, this suggestion is the same as other users. But we all should know, Apache APISIX is a foundation project, and all of our contributors are from all over the world, they have their daily work or private things. Because of love and contribution sense, we all come to Apache APISIX's community, so please be patient and try to involve in our community. If you could provide some cases that which part of documentation could be improved, that would be much better!

本来想从kong尝试转apisix，但是插件还是不习惯，不知道是不是使用姿势不对，如有不正请指教，希望国产的越来越好，忍不住吐槽下

For now, Apache APISIX is used in many companies around the world, mainly in China AFAIK, you could learn more about Best Practices from https://apisix.apache.org/zh/blog/archive/. Also, we have a weekly meeting tomorrow evening, welcome to take part in and share your thoughts 😄 See #5721 for the Meeting link.

For other questions, let's wait for others' replies.

[solo-xwz]

When you only need to update one plugin under a consumer, you must first get all plugins information for each update, and then put them all after change, which is very troublesome and wastes bandwidth. Why not add a PATCH method for .../consumers/{consumer_name}/plugins/{plugin_name} or .../consumers/{consumer_name}?
I guess it might be the limitation of etcd.
By the way, because there are some business requirements, we can only interact with certain gateway plugins through the admin api, but cannot use the dashboard.

[juzhiyuan]

Get it, maybe you could draft a PR and implement the PATCH method?

cc @tzssangglass

[tzssangglass]

yes, we can add PATCH for consumer, PR is welcome!

[juzhiyuan]

Hi @solo-xwz, may I know if we could arrange an online meeting or chat? I'd like to know more details about your experience on using Admin API.

My mail is juzhiyuan@apache.org and my WeChat is JuShaoyao 😄

[solo-xwz]

Hi @solo-xwz, may I know if we could arrange an online meeting or chat? I'd like to know more details about your experience on using Admin API.

My mail is juzhiyuan@apache.org and my WeChat is JuShaoyao 😄

I have temporarily switched back to using Kong,
But it’s okay to communicate, I will add your WeChat.

[moonming]

@solo-xwz thanks for your feedback, very valuable 👍
@membphis please take a look, and IMO we can make Apache APISIX better together

[membphis]

比如一个插件A，应用到全局之后，如果想对某个用户单独设置不同配置的插件A，结果该用户调用的时候，全局和用户下的插件A都会执行，就很尴尬，按一般的逻辑，全局插件应该是优先级最低，最后兜底的吧

client -> global rules -> route rules -> upstream

IN APISIX land, global rules and route rules are completely independent of each other. the plugin limit-count, we can use it both in global rules and route rules at same time. This means that limit-count will be run twice.

新增或修改consumer下的插件，都得PUT全部提交一遍，新增还好，如果想单独修改下某个插件配置，就很麻烦，plugin id也没有

this is a todo feature, welcome PR.
we can create a new issue before we start this PR.

还有个疑问，dashboard为啥直接对接etcd不对接Admin API？

We may indeed do this in the future. This is an optional solution. Welcome to discuss this issue on the mailing list.

插件这块，感觉还是Kong比较好用，可以自由地应用到不同的route、service、consumer组合上，都不应用就是全局的，插件开发文档也差很远，很多要自己看源码才明白

if you have any good idea to make the APISIX doc better, pls let us know. welcome discuss or contribute ^_^

[solo-xwz]

It seems to me that we just chose the order global>consumer>route>service. I'll give you a scenario to counter your point: if the user needs to add a global plugin, like an ua-restriction plugin. If it is in this order consumer>route>service>global, then the spiders request will go through routing, execute some plugins on the route, and finally come to the global ua-restriction plugi. This looks bad. So the problem you're talking about isn't solved by adjusting the order.

I think you may not understand what I mean😅.
The order of consumer>route>service>global only determines which plugins will be executed for a request when there are same plugins, but it does not determine the order of execution of different plugins.
The order of execution depends on the priority attribute of the plugin itself.
If the ua-restriction plugin is only enabled globally, and it's priority in the access phase is higher than other plugins on the route, then all requests will execute ua-restriction plugin first, illegal requests will be rejected directly.

[tzssangglass]

I understand what you are saying. I don't think you understood the scene I was talking about😓

the order of consumer>route>service>global means that when a request comes into APISIX, it is matched to the route first and the global plugin is executed last.

[solo-xwz]

I understand what you are saying. I don't think you understood the scene I was talking about😓

the order of consumer>route>service>global means that when a request comes into APISIX, it is matched to the route first and the global plugin is executed last.

It seems that you still don't understand what I said...
Like the design I mentioned above (actually similar to Kong), the order of consumer>route>service>global only determines which one will be executed when same plugin exists, same plugin is the point,but does not determine the execution order of different plugins,
So why the global plugin must be executed last?

[membphis]

I feel that this design is of little significance, because there are few plugins that need to be executed at the global level and the consumer/route/service level at the same time.

I have different opinions.

The current global rule design is executed before routing matching. For example, IP black and white lists, WAF and other security functions, it requires all requests to execute these security plug-ins.

[solo-xwz]

I feel that this design is of little significance, because there are few plugins that need to be executed at the global level and the consumer/route/service level at the same time.

I have different opinions.

The current global rule design is executed before routing matching. For example, IP black and white lists, WAF and other security functions, it requires all requests to execute these security plug-ins.

This shouldn’t be a problem at all,whether to execute first should depend on the priority attribute defined by the plugin.
What I'm talking about priority of consumer/route/service/global is for the same plugins.
However, I think the current design may increase the processing speed of the global plugin a bit, but it will greatly reduce the flexibility.

[membphis]

@solo-xwz pls use English in public channel

[juzhiyuan]

see #5722 (reply in thread)

I would also encourage to use English 😄 There have some tools like Google Translate that could help you.

[moonming]

@juzhiyuan @membphis @tzssangglass Is there any improvement plan? issue or PR?

[moonming]

issue: #5800