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/

Deploy instructions

• Deploy service - Graph Handler

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), can be used to check if a label being added is an identifier which needs to also set all identifier properties, if true implicitly adds labelCanBeRemoved: false (not immutable/elementCanBeRemoved/allPropertiesImmutable because want case where label is identifier but node can be removed, or properties can be changed)
		immutable: false, // optional (default false), if true implicitly adds labelCanBeRemoved: false, elementCanBeRemoved: false, allPropertiesImmutable: true
		labelCanBeRemoved: false, // optional (default false), if false cannot remove this label from a node once it has been set
		labelCanBeAdded: true, // optional (default true), if false cannot add this label to an existing node
		elementCanBeRemoved: false, // optional (default false), if false cannot delete a node when this label exists
		allPropertiesImmutable: false, // optional (default false), if true all properties are forced to being immutable, including any properties not set in this schema, if false then check per property setting
		restrictProperties: false, // optional (default false), if set can only add properties in this schema
		restrictRelationshipsOutgoing: false, // optional (default false), if set can only add relationships in this schema (only outgoing at the moment, can design schema for incmming later)
		properties: {
			xxx: {
				identifier: false, // optional (default false), if true implicitly adds immutable: true
				immutable: false, // optional (default false), if set cannot be changed/removed/added except on creation
				stringified: false, // optional (default false), if set will stringify/parse property value before inserting/returning
			},
			..
		},
		relationshipsOutgoing: {
			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 check for relationship connected to this node label only, if relationship schema sets immutable: true then this setting is ignored
			},
			..
		},
	}
}

• 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 true implicitly adds elementCanBeRemoved: false, allPropertiesImmutable: true
		elementCanBeRemoved: false, // optional (default false), if false cannot remove this relationship once created
		allPropertiesImmutable: false, // optional (default false), if true all properties are forced to being immutable, including any properties not set in this schema, if false then check per property setting
		restrictProperties: false, // optional (default false), if set can only add properties in this schema
		properties: {
			xxx: {
				identifier: false, // optional (default false), if true implicitly adds immutable: true
				immutable: false, // optional (default false), if set cannot be changed/removed/added except on creation
				stringified: false, // optional (default false), if set will stringify/parse property value before inserting/returning
			},
			..
		},
	}
}

• 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.

Naming in coding conventions

Node Labels and Relationship Types

There is the possibility these might need to be changed in the future eg if clash with other graphs being combined or to match other graphs, or if Neo4j changes its engine, they will also be referenced extensively through code, for this reason we will use code constants to create the names or parts of names for Node Labels and Relationship Types.

Node and Relationship properties

There is less likelihood of these needing to be changed in the future so we will hard-code strings through our code to reference them, this is easier to read than constants.

Working documents

Working_documents - Graph Handler