Per Service Schemas: Difference between revisions
Line 5: | Line 5: | ||
= File Structure = | = File Structure = | ||
* see [[Repository structure | * see [[Repository structure#schemas|Repository structure]] | ||
= Example Per Service Object List = | = Example Per Service Object List = |
Revision as of 15:13, 10 April 2023
Overview
Each service manages a schema of object/resources that it is responsible for, this schema is available to other services and frontends. The schema includes a list of fields available for each object.
File Structure
Example Per Service Object List
- stored in top level schemas folder
{
serviceTag: "xx",
objectTypes: [
"xxx",
"yyy",
// ...
]
},
Example Object Fields Schema
{
objectType: "xx",
canUpdate: true, // whether any fields can be updated
fieldNames: {
xxx: { // fieldName
type: "xx", // string|integer|currency|float|special|..
requiredOnCreate: true,
canUpdate: true,
validation: {}, // maybe ajv syntax
storageResource: "graph" , // |eg:"dynamoDB" , used to find objectTypes added to graph schema
},
// ...
}
},
Example Object Calculated Data Schema
{
objectType: "xx",
calculatedData: {
xxx: { // dataTag
type: "xx", // string|integer|currency|float|special|..
// required requestParams?
},
// ...
}
},
Example Relationships Schema
- stored in top level schemas folder
- parent/child determines relationship direction for graph relationships
- only parent relationships record details for building graph schema?
{
objectType: {
parents: [
{
relationshipTag: "xx", // eg relationship type stored in graph
serviceTag: "xx", // points to the parents serviceTag (maybe optional if in same service)
objectType: "xx", // points to the parents objectTypes
storageResource: "graph" , // |eg:"dynamoDB" , used to find objectTypes added to graph schema
properties: {
{propertyName}: {
//..
}
},
},
// ...
],
children: [
{
relationshipTag: "xx", // eg relationship type stored in graph
serviceTag: "xx", // points to the childs serviceTag (maybe optional if in same service)
objectType: "xx", // points to the childs objectTypes
},
// ...
],
}
},
Generated S3 files
- generate multiple files for different uses, eg:
- list of saved fieldNames for Create
- list of saved+calculated for Update/Info pages
- graphSchemas
- relationships (used by Search/Sort Results)
Use Cases
Standard Create, Update, List, Delete pages
- List and Delete are maybe not required, use table data system instead.
- object schema can add validation information that can be used on the frontend to check before sending to backend, and by the backend to validate the data before handling
Create Object
- can configure what fields are shown
- requiredOnCreate fields must be shown
Edit Object
- users setup any number of pages for object types with configurable fields shown
- fields can be either display only or edit
- each field can adjust it's display properties (perhaps via cssStyles)
Menu Config
When adding menu items can add links to create, update, list, delete objects, user chooses the service then from that service's list of objects and what action is being performed. For update/delete perhaps links to a standard page that asks for the identifier before presenting the page.
Tabled Data
When viewing tabled data the frontend pulls the tableId's config from backend, then when requesting the data also requests the serviceTag > objectType schema for use when displaying the data.
Code Standardization
Code such as middleware validation schema and saving data to databases can be standardized.
Code Generation
Endpoints per object for actions such as create/delete/update could be automatically generated from objectSchema.