Hi @zexuan, Yep, that's right.
On Mon, May 24, 2021 at 11:08 AM Zexuan Luo <[email protected]> wrote: > 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. > >> > >> >
