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