Per Service Schemas

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

• see Repository structure

Example Per Service ObjectTypes.js

• stored in top level schemas folder

[
	"xxx",
	"yyy",
	 // ...
]

Example ObjectSchema

{
	objectType: "xx",
	canDelete: false, // whether any fields can be deleted // default = false
	overWriteHandlers: { // optional, if not set will create default handlers
		create: [], // default: ['hdrApi', 'hdrSqs']
		update: [], // default: ['hdrApi', 'hdrSqs']
		get: [], // default: ['hdrApi', 'hdrInv']
		delete: [], // default: ['hdrApi', 'hdrSqs']
	}
	overwriteGeneratedMainFunction: ["create", "..."], // list of actions that will use user created Main Lambda instead of generated main Lamnbda
	fieldNames: {
		xxx: { // fieldName
			type: "xx", // string|integer|currency|float|special|..
			requiredOnCreate: false, // default = false
			optionalOnCreate: false, // default = false
			canUpdate: true, // default = true
			validation: {}, // maybe ajv syntax
			storageResource: "graph" , // |eg:"dynamoDB" , used to find objectTypes added to graph schema
			fromServiceNameTag: "xxx" , // service responsible for object schema
			fromObjectType: "xxx" , // objectType at fromServiceNameTag
		},
		// ...
	},
	calculatedFields: {
		xxx: { // fieldName
			type: "xx", // string|integer|currency|float|special|..
			// required requestParams?
		},
		// ...
	}
    compositeKeyDeliminator: "xx", // join partitionKey and sortKey
	identifiers: [
	{
		type: "partitionKey",

		fieldNames: ["xx","yy"], // composite partition keys in DynamoDB
		deliminator: "xx",  // optional, defaults to "_"
		name: "zz", // name of field in database
		// or
		fieldName: "xx"
	
	},
	{
		type: "sortKey",

		fieldNames: ["xx","yy"], // composite partition keys in DynamoDB
		deliminator: "xx",  // optional, defaults to "_"
		name: "zz", // name of field in database
		// or
		fieldName: "xx"
	
	},
  ]
},

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
				objType: {
					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
				objType: {
					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:
  1. list of saved fieldNames for Create
  2. list of saved+calculated for Update/Info pages
  3. graphSchemas
  4. relationships (used by Search/Sort Results)

Use Cases

Find Deployed Service Name

• other services can use fixed serviceTag to get deployed serviceName from serviceSchema on S3
• used to build resource names for external services
• eg when one service needs to send a message into an SNS belonging to a different service

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 can be automatically generated from objectSchema.

Code Generation Structure

• npm for generic code generation, can be used in any project, includes functions for generating Source files from templates and developer files
• npm for per project specific files, eg templates for the project (Create/Update/.. code)
• Empty Service Template has GenerateCode.js script file in root dir that is run to generate code, it invokes a generation function from generic npm with param that points to per project npm's templates
• generated Source retains hook tags (and any developer added code), so if developer wants to update developer's file with updated template code they can generate code and simply copy generated Source to src folder