At the moment anything can be persisted via panel page forms. Although the front-end provides a form in theory any data object can be saved as form data. This is not good. Instead users should be able to restrict data to a specific schema using server-side validation to enforce integrity of data being saved. This can be achieved in multiple ways.
Associate schema with bucket and validate data against schema using s3 event before saving object to bucket prefix. This would require coding a lambda to achieve this.
Provide an optional json schema text input for panel page form persistence. Some how verify that the data submitted matches a schema server-side using a lambda.
The question really becomes whether its druids responsibility to enforce integrity of data or whether that responsibility is that of the server cod outside of druid. If druid is focused on front-end than it is really more the responsibility of the back-end developer / tier to create these restrictions. For example, this can easily be done internally using verti-go via serverless framework event functions on s3 objects.
Is verti-go a monorepo that encompasses ALL druids back-end functionality. It really seems so. Where as druid is recipe for building individual front-end shells. is that the right approach with verti-go. Verti-go is a mono repo so it seems appropriate to treat it as a organization wide tool for rapid development of druids when back-end functionality like enforcing data integrity is necessary. We could also closer align validation logic with the front-end to make vert-go less site/org specific and more generic to be used by anyone.
Now that verti-go is working again we can setup a lambda to validate entities pushed to s3 using a strategy like matching a file in a folder for the scmea. If the file exists like based on entity name than validate.
Can do the same thing as css to json. Have dedicated lambda using the below library to validate.
At the moment anything can be persisted via panel page forms. Although the front-end provides a form in theory any data object can be saved as form data. This is not good. Instead users should be able to restrict data to a specific schema using server-side validation to enforce integrity of data being saved. This can be achieved in multiple ways.
Associate schema with bucket and validate data against schema using s3 event before saving object to bucket prefix. This would require coding a lambda to achieve this.
Provide an optional json schema text input for panel page form persistence. Some how verify that the data submitted matches a schema server-side using a lambda.
The question really becomes whether its druids responsibility to enforce integrity of data or whether that responsibility is that of the server cod outside of druid. If druid is focused on front-end than it is really more the responsibility of the back-end developer / tier to create these restrictions. For example, this can easily be done internally using verti-go via serverless framework event functions on s3 objects.
Is verti-go a monorepo that encompasses ALL druids back-end functionality. It really seems so. Where as druid is recipe for building individual front-end shells. is that the right approach with verti-go. Verti-go is a mono repo so it seems appropriate to treat it as a organization wide tool for rapid development of druids when back-end functionality like enforcing data integrity is necessary. We could also closer align validation logic with the front-end to make vert-go less site/org specific and more generic to be used by anyone.
Now that verti-go is working again we can setup a lambda to validate entities pushed to s3 using a strategy like matching a file in a folder for the scmea. If the file exists like based on entity name than validate.
Can do the same thing as css to json. Have dedicated lambda using the below library to validate.
https://www.npmjs.com/package/jsonschema https://www.npmjs.com/package/ajv
Orchestrate via go lambda like convert_media but for entity validation.
Where does json schema come from and how does persisted document map to validation schema?