Sorry for the chart was not shown in the previous email. I resend it here. ------------------------------------------------------------------------ ------------------------------------
Hi folks, Background As we all know that there are two kinds of API in APISIX, one is called Admin API, written in lua, provided by the APISIX instance and the other is Manager API, written in Golang, to serve for the APISIX Dashboard. For now, both APIs are actively maintained and in use. Although they have very much similar functionality which is mainly to validate the request and write data into etcd, there are still some slight differences between them. Admin API has a more complex validation for data schema than Manager API. Let's take https://github.com/apache/apisix/issues/4150 for example, Admin API does have a check on the input body to see if it is base64-decodable for response-rewrite plugin, while there is no such check on Manager API. Meanwhile, Manager API has much more easy-to-use functionalities for users than Admin API, such as plugin orchestration. So in plan, Manager API will come to the stage to completely replace Admin API along with APISIX 3.0. While actually, in order to make Manager API as a pure API for control plane, we still need to move some functionalities related to UE out of it and add some more validations in it. However, this will definitely break the compatibility between Manager API and current APISIX Dashboard. In addition, I've got a little of confused which API should be picked for integration with other projects. For example, the internal architecture chart ( https://github.com/apache/apisix-ingress-controller#internal-architecture) shows that APISIX-ingress-controller is now utilizing Admin API for managing APISIX. End users are using Manager API via web browser. In issue https://github.com/apache/apisix-dashboard/issues/1884 , @bzp1000 is going to create a CLI tool to manage resources in APISIX, then which API shall we choose? Probably we will have the same confusion when introducing other tools, like Terraform. Solution to discuss So in order to make things more clear, after some discussions with some guys and refer to the implementations of etcd, I want to send a proposal to introduce a dedicated control-plane API for APISIX. Please see the following architecture diagram. [image: 657A2236-5B9F-43A0-ADE9-5CA688BF8446.png] Please let me provide more details on this. - The Data Plane only consists of the APISIX, since the previous Admin-API component is completely removed from the APISIX. This will keep APISIX as small and simple as possible. - Move the API layer out of Dashboard, with adding more plugin/schema validation and removing some APIs only related to UE, then we can call it APISIX-apiserver who deserves a dedicated repository. So most of current codes in Manager API could be reused by APISIX-apiserver. - The data schema validations on writing etcd will be and only be performed by APISIX-apiserver. APISIX only needs to do validation on reading from etcd. - Dashboard will be have its own backend APIs, either keeping current Go implementation or building a new one written in Node or anything else. The FE team will be much more free to pick their own solution stack. The new Dashboard backend will turn to give more focus on users experience and complicated business logics, such as plugin orchestration, multi tenants, API lifecycle management, API market, and etc. - APISIX-apiserver provides both gRPC and restful-json(yaml) APIs for clients. gRPC will be the most recommend one. While restful-json(yaml) will also be very helpful for the languages that not well supported by gRPC or some scenarios that gRPC is unusable. - The restful-json(yaml) APIs of APISIX-apiserver is provisioned by the grpc-grpcgateway project which could auto generate all the required codes for restful APIs, by the gRPC protobuf definitions. - The APISIX-apiserver can add backward compatibility support for multiple API versions, which could be well working with various versions of APISIX. - The community could officially maintain several most commonly used gRPC or restful SDKs for developers’ convenience. This will definitely introduce huge changes on current infrastructure. Please no hesitate to tell me what you think about it and any questions that you gonna ask. Also please let me know if I was wrong. Looking forward to you. Thanks. On Mon, May 24, 2021 at 10:35 AM Joey Ma <[email protected]> wrote: > > Hi folks, > > Background > > As we all know that there are two kinds of API in APISIX, one is called > Admin API, written in lua, provided by the APISIX instance and the other is > Manager API, written in Golang, to serve for the APISIX Dashboard. For now, > both APIs are actively maintained and in use. Although they have very much > similar functionality which is mainly to validate the request and write > data into etcd, there are still some slight differences between them. Admin > API has a more complex validation for data schema than Manager API. Let's > take https://github.com/apache/apisix/issues/4150 for example, Admin API > does have a check on the input body to see if it is base64-decodable for > response-rewrite plugin, while there is no such check on Manager API. > Meanwhile, Manager API has much more easy-to-use functionalities for users > than Admin API, such as plugin orchestration. > > So in the plan, Manager API will come to the stage to completely replace > Admin API along with APISIX 3.0. While actually, in order to make Manager > API a pure API for the control plane, we still need to move some > functionalities related to UE out of it and add some more validations to > it. However, this will definitely break the compatibility between Manager > API and the current APISIX Dashboard. > > In addition, I've got a little confused about which API should be picked > for integration with other projects. For example, the internal architecture > chart ( > https://github.com/apache/apisix-ingress-controller#internal-architecture) > shows that APISIX-ingress-controller is now utilizing Admin API for > managing APISIX. End users are using Manager API via the web browser. In > issue https://github.com/apache/apisix-dashboard/issues/1884 , @bzp1000 > is going to create a CLI tool to manage resources in APISIX, then which API > shall we choose? Probably we will have the same confusion when introducing > other tools, like Terraform. > > Solution to discuss > > So in order to make things more clear, after some discussions with some > guys and refer to the implementations of etcd, I want to send a proposal to > introduce a dedicated control-plane API for APISIX, which is provided by > the new APISIX-apiserver project. Please see the following architecture > diagram. > > > Please let me provide more details on this. > > - The Data Plane only consists of the APISIX, since the > previous Admin-API component is completely removed from the APISIX. This > will keep APISIX as small and simple as possible. > - Move the API layer out of Dashboard, add more plugin/schema > validation and remove some APIs only related to UE, then we can call it > APISIX-apiserver who deserves a dedicated repository. So most of the > current codes in Manager API could be reused by APISIX-apiserver. > - The data schema validations on writing etcd will be and only be > performed by APISIX-apiserver. APISIX only needs to do validation on > reading from etcd. > - Dashboard will have its own backend APIs, either keeping the > existing Go implementation or building a new one written in Node or > anything else. The FE team will be much freer to pick their own solution > stack. The new Dashboard backend will turn to give more focus on users > experience and complicated business logic, such as plugin orchestration, > multi-tenants, API lifecycle management, API market, and etc. > - APISIX-apiserver provides both gRPC and restful-json(yaml) APIs for > clients. gRPC will be the most recommend one. While restful-json(yaml) will > also be very helpful for the languages that not well supported by gRPC or > some scenarios that gRPC is unusable. > - The restful-json(yaml) APIs of APISIX-apiserver is provisioned by > the grpc-grpcgateway project which could auto-generate all the required > codes for restful APIs, by the gRPC protobuf definitions. > - The APISIX-apiserver can add backward compatibility support for > multiple API versions, which could be well working with various versions of > APISIX. > - The community could officially maintain several most commonly used > gRPC or restful SDKs for developers’ convenience. > > > > > This will definitely introduce huge changes to the current infrastructure. > Please no hesitate to tell me what you think about it and any questions > that you gonna ask. Also please let me know if I was wrong. Looking forward > to you. Thanks. > >
