This new way is very different from the old one. I love this new way.
According to this idea, plug-ins will be more like micro-plug-ins, and we can execute these micro-plug-ins one by one by way of arrangement. And will make these micro plug-ins become more independent and simple. On Fri, Jun 19, 2020 at 5:26 PM Ming Wen <[email protected]> wrote: > Hello, > I want to discuss a new idea about plugins, and let me start by explaining > the existing plugin mechanism, plugins works according to the following > rules: > - plugins are executed after the administrator binds them to a route, > service, unless they are modified again by the admin API > - plugins are executed in order of priority which hard code > - plugins are independent of each other, the results of a plu-in will not > affect another plugin > > So, some scenarios are not handled very gracefully by Apache APISIX, such > as: > - limit-count for some IPs, and others are unrestricted > - throw the failed authentication logs to kafka topic A, and others to > kafka topic B > - request which block by limit-req need to go through the fault injection > plugin > > For these scenarios, we can now only handle them by creating multiple > routes, or creating new plugins. > > So I think it's time to take `brain` to APISIX to orchestrate plugins. We > can add an additional plugin orchestrator without any modifications to the > existing plugins, then we can use decision tree to control plugins. > > What do you think? > > Thanks, > Ming Wen, Apache APISIX & Apache SkyWalking > Twitter: _WenMing > -- *MembPhis* My GitHub: https://github.com/membphis Apache APISIX: https://github.com/apache/incubator-apisix
