Hi, After rethinking this issue, I have the following proposal:
In the current architecture where DP and CP are separated, each party needs to maintain JSONSchema data. Moreover, when APISIX is upgraded (API field additions and deletions, plugins and their field additions and deletions), Dashboard also needs to finish adapting and releasing new versions as soon as possible, otherwise using a mismatched Dashboard will write data in ETCD that APISIX may not support and create new problems. Therefore, global hinting in Dashboard is not desirable and does not solve the fundamental problem. To solve the problem of Dashboard and APISIX adaptation, the following plan is adopted, divided into 3 phases. **Phase 1** The first phase requires a quick solution to the problem in the following way. 1. Now, the latest version of Dashboard is 2.7, and the latest version of APISIX is 2.7. 2. Disregard the historical version matching problem and deprecate the version matching logic (manually maintaining a Mapper). 3. Compare Dashboard 2.7 with APISIX 2.7 and sort out where Dashboard's existing features are inconsistent with APISIX (API fields, plugin schema). 4. Update Dashboard to match the existing features with APISIX 2.7 and release version 2.7.1. **Phase 2** The second phase requires enriching Dashboard functionality to match APISIX functionality. 1. Sort out which APISIX 2.7 features are not implemented in Dashboard 2.7.1, such as Stream Proxy, Service Discovery, etc. 2. Update the Dashboard to include the existing features of APISIX 2.7 and release version 2.7.2. **Phase 3** Phase 3 requires the Dashboard to synchronize the APISIX release schedule and release APISIX with the same version number, e.g., 2.8, within a manageable time frame after the release of APISIX. 1. APISIX milestones are visible in GitHub. 2. After APISIX is released, sort out what is different between APISIX and the previous version, and then adapt it in Dashboard. **Another Phase (Long-term solution)** In addition, I have a long-term plan, the current architecture is to separate DP and CP, and the ManagerAPI in CP does a lot of functions that AdminAPI duplicates, so we might as well deprecate ManagerAPI and turn Dashboard into **a pure Web project**, directly accessing AdminAPI, so that when the data in the Request Body is illegal, AdminAPI will return an error directly. Of course, this requires a more detailed solution design and is a big change. What do you think? Best Regards! @ Zhiyuan Ju <https://github.com/juzhiyuan> Zhiyuan Ju <juzhiy...@apache.org> 于2021年7月14日周三 下午1:46写道： > Hi, > > Currently, Apache APISIX Dashboard and Apache APISIX are two separate > projects (hereinafter referred to as Dashboard and APISIX). Whenever APISIX > changes the content (e.g., APIs, API fields, Entity definitions, etc.), > Dashboard needs to match the changes and publish a new version. > > Because the Apache APISIX Dashboard's version number is not the same as > Apache APISIX, then users get confused when using the Dashboard, so I draft > a proposal to support showing incompatible information more clearer on the > Dashboard.[1] > > Due to there have some prototypes I made, so I put them in the GitHub > issue[1], looking forward to your feedback! > > [1] > https://github.com/apache/apisix-dashboard/issues/1944#issuecomment-879607016 > > Best Regards! > @ Zhiyuan Ju <https://github.com/juzhiyuan> >
