imjoey commented on issue #1884:
URL:
https://github.com/apache/apisix-dashboard/issues/1884#issuecomment-841145282
> How about following a `Client-Server` architecture similar to industry
standard
> for eg,
>
> 1. `etcd` & `etcdctl`
> 2. `kube admin api` and `kubectl`
>
> As manager-api gradually will become feature rich, heavy and its
functionality is more like a server. So why not a suitable lightweight client
binary from our's end for communication.
>
> maybe we can consider `apisixctl` :)
> A substitute to manage everything related to manager-api and more through
the command line, from login to fetch, put data everything.
> Development flow will be great and there will always be an opportunity to
extend its feature.
>
> How does it sound?
+1 agreed with following the `Client-Server` architecture.
In addition to directly read/write models from/into etcd, both the
Admin-API within APISIX and the Manager-API within Dashboard are also doing
quite a lot of schema and data validations. This ensures only valid data could
be written into etcd. So if we are going to make the CLI tool directly interact
with etcd, those similar validation codes need to be rewritten which is rather
redundant.
I think this issue is greatly related to the upcoming job `Replacing
Admin-API with Manager-API` because we need to decide which API ( Admin-API or
Manager-API) will be called by the CLI tool.
For now, Admin-API has more comprehensive schema validation than
Manager-API, meanwhile, Manager-API has more functionality than Admin-API. So
actually the replacing work means **Consolidation**.
The following diagram shows the design in my mind. ( I have to admit that
this is really a long-run job. 😄 )
```
+-------------------------------------------------+
|
Control-Plane |
+------------------------------------+ |
|
| Data-Plane | |
|
| | | +-----+ +-------------+
+-------------+ |
| | | | CLI | | Dashboard | |
ingress-ctl | |
| | | +--+--+ +------+------+
+------+------+ |
| | | | | |
|
| | | | | |
|
| Users requests | |
+--v-----------v---------------v------+ |
| | | | APISIX-api-sdk(Go/Nodejs/...)
| |
| | | |
+-----------------+-------------------+ |
| | | | |
|
| | | | |
|
| +----------v----------+ | |
+-----------------v-------------------+ |
| | APISIX(lua) | | | | APISIX-apiserver(Go)
| |
| +----------^----------+ | |
+-----------------+-------------------+ |
| | | | |
|
| | | | |
|
|
+----------+-------------+-+--------------------v-------------------+ |
| | | | ETCD
| |
|
+------------------------+-+----------------------------------------+ |
| | |
|
| | |
|
+------------------------------------+
+-------------------------------------------------+
```
Please let me elaborate on the above design:
- The Data Plane only consists of the APISIX, since the previous `Admin-API`
component is completely removed from the APISIX
- 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
- All the validations of data and schema will **ONLY** be performed by
APISIX-apiserver
- Perhaps the Dashboard will keep the Go backend, or maybe reimplemented in
Node? 😄
- In order to communicate with APISIX-apiserver, we need various SDKs for
developers' convenience
- The APISIX-apiserver can add support for multiple API versions, which
could be compatible with multiple version model definitions along with APISIX
releases.
So please let me know what do you think, any feedback is very welcome. Then
we could find the step-by-step solution to build the CLI tool. 😄 Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
