Open dgarros opened 1 year ago
If the frontend is splitting the schema in multiple components in the schema view, each component can handle only a part of the schema
So maybe having a parameter in the schema endpoint to query only part of the schema would help the frontend to not query the whole schema on each update, and to be able to update just some parts of it
Having something like /api/schema/{id}
may be useful to get only the information for a specific node (object, attribute, relationship, etc), so when updating a part of the schema after an update, only that current part will be fetched again
What about the filters? is it computed in the backend or is a user supposed to be able to update them too?
To be sure that it's clear, for the frontend: we should be able to do the update from:
Add/Remove a value in an Enum
both edit / create views (forms) + schema view
Add/Update/Remove an Attribute on an existing model
both edit / create views (forms) + schema view
Add/Update/Remove a relationship on an existing model
both details view (add / remove a tab) + schema view
Add/Update/Remove a node or a generic
schema view
And what happens when we update an attribute of an object to the other objects values?
Improvements for the schema storage in the frontend is needed to have a better schema management in the frontend (https://github.com/opsmill/infrahub/issues/1382)
Component
Frontend UI, API Server / GraphQL
Describe the Feature Request
The flexibility offered by Infrahub to modify the schema on the fly is one of its main differentiators.
Today the modification of the schema must be done via the /api/schema/load endpoint and it requires a schema file in YAML or JSON format. The end goal is that a user should be able to modify any part of the schema directly in the frontend.
A new set of GraphQL mutations will be required to expose the main operations that we need to support. Below is a list of the main mutations that we need to add, ordered by level of complexity:
In the Frontend, the manipulation of the schema should be available both in a dedicated section reserved for the schema management but, whenever possible, directly within a create or update forms.
Describe the Use Case
The end goal is that a user should be able to modify any part of the schema directly in the frontend.
Additional Information
Some operations won't be available at first until we have a proper support for these changes in the schema migrations.