juzhiyuan commented on issue #1944: URL: https://github.com/apache/apisix-dashboard/issues/1944#issuecomment-885051655
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** 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? -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
