Description
🔖 Feature description
Introduction
When developing with Appwrite everything covers from the Developer side:
- Authentication and Autherztion
- Database
- Realtime
- Storage
- etc.
When there's a need for a data entry (and management) we can choose one of the following approaches.
- Using Client side SDK, is very limiting.
- Using Server side SDK, is the most common way (IMO).
- Using CLI side SDK, is pretty rare.
- Using the Console itself, is common when the developer is the one who is in charge of entering the data.
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
- Custom domain/path.
- Basic User access-level (teams) management.
- Tracking activity (who did what).
- Simple, yet powerful builder.
- A wide variety of CRUD views including relationships and storage.
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
- Users
- Permission group (teams)
- Settings
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
- List (a smart ajaxable data-tables)
- Create/edit form
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:
- Add Users.
- Assigning a user to a permission group(s).
Permission group.
Permission groups are Teams that can be declared to have the following permission for a CRUD view.
- Full - read/write/create/delete.
- Moderate - read/write/create
- Reviewer - read/write
- Viewer - read
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
- Predefined theme or create a custom one.
- Language and direction (LTR & RTL)
- Custom logo for the back office.
- Any other suggestions...
The technical details
The back office will be a standalone package (like the console) built with SvelteKit and
- Will use the
_console_usersbase table (or any newly created one that this not attached to a project) - the easiest one.
OR - Will two new tables
_[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?
- I checked and didn't find similar issue
🏢 Have you read the Code of Conduct?
- I have read the Code of Conduct