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/ObjectRelationships.js

• File that lists relationshipTag that responsible for this service
• Each relationshipTag shows 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/{folderName}/ObjectFieldSchema.js

• normally folderName will be the name of objectType and ObjectFieldSchema.js will contain objectSchema of objectType.
• ObjectFieldSchema.js can contain multiple objectSchema in one file, When contain multiple ojectSchema mostly will contain parent objectSchema and objectSchema that extended from the parent.

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

...