In the earliest versions, APISIX used Openresty as the runtime, but OpenResty often failed to meet APISIX's scalability needs. To solve this problem, we built apisix-base and have been running on it for over a year.
For example, these features can only run in the apisix-base environment: * upstream.tls: Enables secure communication between APISIX and upstream servers. * etcd.tls: Enables secure communication between APISIX and etcd clusters. * xrpc/redis: The Redis protocol support allows APISIX to proxy Redis commands, and provide various features according to the content of the commands. * Dubbo proxy: Supports proxying Apache Dubbo requests. * client-control Plugin: The client-control Plugin can be used to dynamically control the behavior of NGINX to handle a client request, by setting the max size of the request body. * Gzip Plugin: The gzip Plugin dynamically sets the behavior of gzip in Nginx. * Wasm Plugin: Allows loading and running WebAssembly modules in APISIX. * Prometheus Plugin: Optimizing long tail requests caused by excessive data volume in metrics. * proxy-control Plugin: The proxy-control Plugin dynamically controls the behavior of the NGINX proxy. * Real-ip Plugin: The real-ip Plugin is used to dynamically change the client's IP address and port as seen by APISIX. Although we still retain compatibility with OpenResty, in practice, the incompatibility issues between APISIX and OpenResty are often unresolved. Our usual approach is to skip these issues. Considering that APISIX will continue to add new features and bug fixes in the future, these features are often not supported in native OpenResty. At the same time, we also need to consider compatibility with OpenResty, which requires extra maintenance work in testing and development. By dropping support for OpenResty, we can remove extra CI jobs and version checks, making the code simpler. What about your opinion?
