My summary for your idea is: 1. move manager-api as a separate project (apiserver), and extend it. 2. fill the gap between manager-api and admin-api
Am I correct? Joey Ma <[email protected]> 于2021年5月24日周一 上午10:38写道： > 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. >> >>
