Repository structure

Overview

Standard file and folder for each backend microservice.

Root directory

app

The app folder holds all logic for the service, the files inside this folder are a single serverless/node project.

config

The config folder has files that are shared by both app and resource projects, most per-deploy settings are saved here.

resource

The resource folder is a stand alone serverless/node project that deploys resources that should not change often, deploying as a separate stack gives some protection against damaging resources such as databases when making regular changes to logic.

files

.gitignore

Global .gitignore for entire git project

COPYING

Standard license information

README.md

Landing page when viewing the project on repository host

GenerateCode.js

Standard script that invokes npm library to generate code for this service

app project

initial_setup

Offers a method to setup an initial instance of the service.

config.js

Configurable details that will be implemented during initial setup

initialSetup.js

Logic that performs the initial setup, is deployed as a Lambda function and expected to be run once after deployment, after invoked it can be removed or disabled on AWS

src

Per service logic created by developers (not generated), can be split into subfolders per object or work flow, up to developers

Lambda function filenames

Most Lambda functions have a main function file and one or more handler functions, different handler functions handle different sources and adjust the received request so it enters the main function file with the correct params, and also handle batch processing if the source requires it.

Lambda functions that are part of the same closely tied workflow should have the same filename prefix so they group together.

The main function adds prefix "_Main", handler functions add prefix "_Hdr..." replacing the dots with the handlers source, "Sqs" for SNS>SQS triggers, "Dsq" for direct SQS triggers, "Api" for API Gateway, "Inv" for Lambda direct invoke.

Example filenames for a workflow that has 4 functions that connect with Graph Handler invocations:

• ThisFunction_Main
• ThisFunction_HdrSqs
• ThisFunctionNodeCreated_Main
• ThisFunctionNodeCreated_HdrSqs
• ThisFunctionXxNodeUpdated_Main
• ThisFunctionXxNodeUpdated_HdrSqs
• ThisFunctionYyNodeUpdated_Main
• ThisFunctionYyNodeUpdated_HdrSqs

Developer code added to generated code

When adding developer code into generated code we place the developer code into /src/{objectType}/{generated file type}.js files, example adding code to SellOffer > Create handler would be in /src/SellOffer/Create.js

lib

The lib folder stores functions that are used by multiple Lambda functions

schemas

schemas/objectList.js

• file that lists all objectTypes controlled by this service

schemas/objectRelationships.js

• File that lists relationshipTag that responsible by this service
• Each relationshipTag show parent and children objType that use this relationshipTag

schemas/refObjectRelationships.js

• Show relationshipTag of each objType in service
• Point to service that responsible for relationshipTag

schemas/objectFields

• sub-folder with one file per object type
• fields for data that is set by a user and stored in state such as a database
• each file exports a javascript object and each file is one objectType with it's objectType as the filename

schemas/objectCalculatedData

• sub-folder with one file per object type
• fields for data that is calculated, may or may not be stored in state
• each file exports a javascript object and each file is one objectType with it's objectType as the filename

Source

Code created by code generation from project schemas, do not edit these files by hand as they are auto-generated and disposable.

__test__

Holds code that executes local unit tests

resource project

...