🚀 Feature: Appwrite Admin no-code customized back-office. #5760
Comments
|
If this feature will be approved I can chip in with the development process. |
|
Hey, definitely love this! Could be possible in future |
|
While I see the appeal, Appwrite is a Cloud backend platform and not a no-code tool. Our focus is on enabling developers to be more productive by giving them the backend tools they need throw APIs and SDK. With each tool you have to understand your audience and abstractions layers. One rule we always followed in Appwrite is that are abstraction starts in the backend layer and ends in the API layer. We never touch the developer UI or should we be opinionated about how it should be build. The described above is already out in the wild with many no-code platforms, many of them already integrate with Appwrite. We will always love to add and support more integrations like this. That said, never say never, but if we do decide to do something like this, it would most likely be a separate product to Appwrite. |
🔖 Feature description
Introduction
When developing with Appwrite everything covers from the Developer side:
When there's a need for a data entry (and management) we can choose one of the following approaches.
The problem with the first 3 methods is that it requires the developer to develop that backend office again and again for any new project.
The last approach is very hard to use as you don't have a way to control the data flow, track it, and strict it with permissions.
A Solution
Adding an all-in-one Appwrite backend builder.
The builder will be composed of many common use cases with Appwrite data, and the building process won't be targeted the darg-n-drop features, as it will be targeted the solution of being able to quickly deploy an internal tool that will use Appwrite Database and Storage.
Using the backend builder will be easy and fast, and will give an easy way to allow customer and level-based users to add data to their Appwrite project.
Features
Builder Overview
In order to add a back office to a project there will be a need to activate the service per-project.
Then the user will be able to access the newly added menu to manage the back office.
Inside this page, the user will have three tabs
Views
In the view section, the user can add a view.
A view is a CRUD operation group.
For example, in an e-commerce website, the user will be able to add a products view that will have
Users
For now, the managing of the user will be only through this tab - although in the future it can be added to the generated back office - and the user can:
Permission group.
Permission groups are Teams that can be declared to have the following permission for a CRUD view.
One permission group can be used for many CRUD views.
Settings
In the settings section, the user will be able to manage common backend settings
The technical details
The back office will be a standalone package (like the console) built with SvelteKit and
_console_usersbase table (or any newly created one that this not attached to a project) - the easiest one.OR
_[ID]_backoffice_users&_[ID]_backoffice_teams🎤 Pitch
When using Appwrite as BaaS it will be much easier to have all the necessary parts for the development in one place. Instead of the need to use other/separate services.
👀 Have you spent some time to check if this issue has been raised before?
🏢 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: