Service - Graph Handler

Overview

Service that manages a graph database, intended to be deployed any number of times, each instance managing one graph within a project. Most project relationships will be stored in graphs, other services can duplicate subsets of relationship data or element data if they choose or can use the graphs as their store.

As the project grows relationship data can be extended to allow for analysis of relationships, weighting same type connections etc..

Use standardized labeling of nodes to allow graphs to be merged or connected later.

Repository

https://bitbucket.org/stb_working/graph-handler/src/master/

Neo4j graph

Scales well with a large number of node labels / relationship types.

DynamoDB tables

Standard Config Table Per Service

Configuration tags

...

NodeSchema

{
	nodeLabel: "xx",
	schema: {
		identifier: false, // optional (default false), if set implicitly adds immutable = true
		immutable: false, // optional (default false), if set cannot be removed or added except on creation
		restrictProperties: false, // optional (default false), if set can only add properties in this schema
		restrictRelationships: false, // optional (default false), if set can only add relationships in this schema (maybe only outgoing relationships?)
		properties: {
			xxx: {
				identifier: false, // optional (default false), if set implicitly adds immutable = true
				immutable: false, // optional (default false), if set cannot be changed/removed/added except on creation
			},
			..
		},
		relationshipsOutgoing: { // (maybe only outgoing relationships?)
			xxx: {
				immutable: false, // optional (default false), if set relationships of this type connected to a node with this label cannot be removed after added. Not yet implemented, this would be a second change to set to true if relationship schema immutable set to false, related only when attached to this nodeLabel
			},
			..
		},
	}
}

• settings per node label
• if multiple labels are supplied in a query for a node (eg if have multiple identifier labels) we combine (or iterate through) all relationship/property settings when validating query

RelationshipSchema

{
	relationshipType: "xx",
	schema: {
		immutable: false, // optional (default false), if set cannot be removed
		restrictProperties: false, // optional (default false), if set can only add properties in this schema
		properties: {
			xxx: {
				identifier: false, // optional (default false), if set implicitly adds immutable = true
				immutable: false, // optional (default false), if set cannot be changed/removed/added except on creation
			},
			..
		},
	}
}

• global settings for relationship types

Query language

Focus on using Cypher.

Querying data in graph database

Planning all Put/Update/Delete/CRUD queries to pass through an API/Graph Handler Lambda functions.

Read/Get queries could query the graph directly using eg IAM constraints/throttling, but currently unable to lock the EC2 on a private server and allow Lambda's outside of the VPC to access the database, so all requests will pass through Graph Handler Lambda functions until infrastructure allows for a better design.

Node/relationship schema

setup

Each service sends schema to graph handler in InitialSetup. If we do this directly by put into Dynamo then the access to do this is deleted along with the IntialSetup Lambdas. We could alternatively have a Lambda in the GraphHandler that does it but we would want to remove that once complete.

Graph actions like setting constraints would need to be handled by a Lambda.

Working documents

Working_documents - Graph Handler