One vote for remove it. The benefits of introducing it are significantly less than the drawbacks of introducing it.
Leslie Tsang leslie.ts...@icloud.com > On 21 Jan 2022, at 3:06 PM, Zeping Bai <bzp2...@apache.org> wrote: > > Yes, I also think we should remove it. Its existence at this stage makes it > more difficult for users to develop to extend the functionality of APISIX > Control Plane (its own lack of documentation makes it difficult to use), and > it can also cause security issues due to improper use. > > Best regards! > Zeping Bai @bzp2010 > > Bozhong Yu <imbozh...@gmail.com> 于2022年1月21日周五 14:22写道： > >> Hi, Community. >> >> We use droplet(https://github.com/ShiningRush/droplet) for manager-api >> now, which is wrap gin framework , and it is designed to prevent user >> care concrete logic. But it limits what we can do to extend the dashboard, >> I think we should remove it in v3. >> >> Baoyuan <baoyuan....@gmail.com> 于2021年12月22日周三 10:10写道： >> >>> Hi, I was very excited to see the discussion about the new version of >>> Dashboard. >>> >>> I have the following thoughts about the new version of Dashboard: >>> >>> 1. More secure and reliable >>> >>> In the current Dashboard, manage API manipulates data directly; if the >> JSON >>> schema and APISIX do not match, this can confuse and create confusion for >>> users. For example, data created with APISIX cannot be adequately edited >> on >>> Dashboard. In addition, synchronizing JSON schema adds significant >>> maintenance costs. >>> >>> To solve this problem, I think the manage API can forward requests >> directly >>> to the admin API, eliminating the cost of synchronizing JSON and making >>> Dashboard behave the same as APISIX. >>> >>> The Dashboard provides complex forms to configure resources, which gives >>> users a good editing experience. Still, some overly complicated forms are >>> prone to bugs and have some efficiency issues. Therefore, the new version >>> should provide optional forms for resource editing, either in YAML or >> JSON, >>> to address these issues. Finally, provide an excellent editor to >>> create/edit resources directly by modifying YAML or JSON. >>> >>> 2. Lightweight and highly scalable >>> >>> The current Dashboard build took me almost ten minutes :( >>> The next version could use more advanced technology instead of webpack, >>> such as vite or swc? This will shorten the time for both developers to >>> start the development environment and users to build the project. >>> >>> For some of these functions, we can design them as optional, which can be >>> pluggable as mentioned by Zhiyuan, to ensure good scalability under the >>> premise of being lightweight. >>> >>> 3. A more user-friendly display >>> >>> Many users have a blurred concept of consumer and services. Can we make >> it >>> more straightforward for users to use these two concepts through >> front-end >>> visualization efforts? >>> Rather than just implementing the CURD of resources? >>> >>
