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? > > >
