atajo-cli

Atajo Command Line Interface

Introduction

This module provides an easy to use interactive Command Line Interface (CLI) to interact with the Atajo Mobility Core. This includes developing your lambdas, deploying apps to the Atajo App Store, and running the Lambda Agent

Installation

npm install -g atajo-cli

Running

If you run :

atajo

You will get a help menu describing the various commands you can run.

Registering a domain/secret key.

In order to test lambdas or run the Lambda Agent, you need to register domains with their corresponding secret keys that the atajo-cli can use to process transactions.

atajo register add <domain> <secret>

You can also list loaded domain/secret combinations with the following command

atajo register list

Working with Lambdas

You can create the events and sample lambdas in the current directory to get started. Full stack developers would prefer creating this in their app project directory to have both front-end and back-end in the same place, however, you can create, run and deploy your lambdas from any directory (that could be in a seperate git repository)

Creating basic lambdas in the current directory :

atajo lambda create

Once you have registered a domain/secret, you can test your lambdas locally by running :

atajo lambda test <domain>

Alternatively, you can run / test your lambdas locally in a container by running [WIP] :

atajo lambda run <domain>

When you are ready to deploy your lambdas to the cloud, you can run [WIP] :

atajo lambda deploy <domain> <service>

Where service is one of :

• azure
• aws
• mcp

Lambda Structure

class SampleLambda {
 
   constructor(api, config, log, dbi) {
 
        //api -> STUB: To be implemented
        //config -> object containing release and domain
        //log -> bunyan log: lob.debug(...); lob.info(...); lob.warn(...); lob.error(...); 
        //dbi -> the mongo database interface
 
   }
 
   request(tx) {
   
       //Transaction rejected.
       tx.reject({});
 
       //Transaction resolved.
       tx.resolve('Lambda response');
 
   }
 
}
 
//The following binds the Lambda to the Atajo Lambda Agent to commence receiving transactions
require('./atajo/lambda').bind(SampleLambda);

Lambda Globals (DEPRECATED -> USED BY LEGACY LAMBDAS)

There are 2 globals loaded for your lambda. The first is log and the second is dbi :

The log global exposes a standard bunyan logging interface with :

log.debug
log.info
log.warn
log.error

The dbi global exposes pre-loaded schemas you define in your lambdas/schemas directory. For example :

#./lambdas/schemas/sampleSchema.js 
 
module.exports = {
    dateTime: String,
    uuid: String,
    user: String,
    sync: String,
    obj: String
};
 

Then to query the database :

dbi.samples.find({}).limit(10).then(result => {...}).catch(err => {...})

In this case sampleSchema is automatically stripped of the Schema part and an s added in the exposed dbi global, for example :

userSchema.js => dbi.users
deviceSchema.js => dbi.devices

Besides connecting and loading schemas (which is handled for you), you can use all functionality available with the mongoose npm module (see http://mongoosejs.com/docs/guide.html)

Examples:

 
#Create a new record:  
var sample = new dbi.samples(); 
sample.uuid = '1234'; 
sample.user = 'john'; 
sample.save().then().catch(); 
 
#Query for a record: 
dbi.samples.findOne({uuid:'1234'}).then(result => {...}).catch(error => {...}); 
 
#Query for multiple records:  
dbi.samples.find({user:'peter'}).then(results => {...}).catch(error => {...}); 
 
#Remove record(s):  
dbi.samples.remove({user:'peter'}).then(result => {...}).catch(error => {...}); 
 
#Update a record 
dbi.samples.update({uuid:'1234'}, {$set: { user: 'peter'}}).catch(err => {...}); 
 

Creating an Atajo enabled app

We are currently working on an Ionic3 generator. For now you can manually add the Atajo client libraries to your Ionic3 app. See https://www.npmjs.com/package/atajo-ionic

Remotely updating currently deployed apps (Code Push)

atajo app update

You will be prompted for various parameters :

• platform - android or ios (Default: android) - Platforms are seperated so updates can be pushed seperately
• domain - A registered domain you would like to authenticate with
• release - qas or prd (Default: qas) - Dev apps are supported since a developers can rebuild apps containing their latest code themselves
• changelog - A description or comma seperated list of changes (If commas are used, they are parsed into a list in the update notification on the app)

Once completed, your app will be registered, deployment keys created/updated and your latest code pushed for deployment.

Deploying apps to the Atajo App Store

COMING SOON

Changelog

Version 0.0.101 - 0.0.102

• Removes requirement for pid disk cache
• Replaces disk cached payloads and IPC triggers with MQTT tx and rx queues
• Fixes bug where auto-reconnect fails under some conditions
• API Definition upload logic moved to seperate class
• Adds more MS Insights reporting at a Lambda level for tx statuses
• Consul polling replaced with async refresh call
• Enforces websocket only connection to core

Version 0.0.100

• Adds debug logging to collector <-> lambda communications
• Fixes issue where chunkTotal == 0 breaks client

Version 0.0.99

• Buffered and Compressed responses now optional
• Re-implemented reconnect logic independent from consul refresh - on disconnect w/ 5 second interval

Version 0.0.98

• Compression only applied to resolved data not if type Buffer

Version 0.0.97

• NPM audit clean
• Inline compression of lambda responses (Pako)

Version 0.0.96

• Migrates rxjs to 6+
• Enables automatic reconnection with back off to Atajo Core if connection drops for some reason

Version 0.0.95

• Includes resolved data buffer management for larger payloads
• Auto convert all resolved data to binary buffers
• Reworked controller / lambda interface - prepares controller API for lambdas in other languages (GoLang first)
• Removes requirement for tx/rx pid disk cache
• Improved transaction processing speed

Version 0.0.94

• Updates socket.io-client to work with latest Atajo Core
• Sends identity (consul config) to lambdas

Version 0.0.93

• Insights key now configurable from consul

Version 0.0.88-92

• Fixes Insights related issues.

Version 0.0.87

• Fixes lambda process error reporting bug.

Version 0.0.86

• Adds App Insights to various events.

Version 0.0.84-85

• Fixes problem with Lambda suicide
• Add configurable Lambda suicide timeout (default: 5 minutes)

Version 0.0.82-83

• Internal Updates

Version 0.0.81

• Updated Readme
• Adds pretty printed stream logs
• Fixes problem where not config was found for Mongo
• Skips attempted Mongo init if no config exists (Speeds up Lambda time-to-configure)

Version 0.0.68-80

• Internal Updates

Version 0.0.67

• Updated Readme
• Fixed API definition bug with multiple versions

Version 0.0.66

• Updated Readme
• Minor changes

Version 0.0.65

• Updated Readme
• Minor changes

Version 0.0.64

• Updated Readme

Version 0.0.63

• Updated Readme
• Optimized Lambda lifecycle management
• Boosts Lamdba performance

Version 0.0.62

• Updated Readme
• Minor changes

Version 0.0.61

• Updated Readme
• Minor changes

Version 0.0.60

• Updated Readme
• Minor changes

Version 0.0.59

• Updated Readme
• Changes atajo lambda test to atajo lambda run
• Directory nested lambdas now allowed (e.g. TX to @atajo-lambda/v1/auth/general will map to v1/auth/general.js lambda)
• API Definitions :
  • Now in JSON (YAML deprecated)
  • Moved to definitions subdirectory
  • Seperate header.json and endpointName.json for endpoints
  • May be nested for more order
• Added cache path and getter (implicit setter) to config object passed to lambdas - e.g.

 constructor(api, config, log, dbi) {
    ...
    // A directory called myCacheName is created under whichever mount the lambda is internally configured to use
    this.cachePath = config.cache.get("myCacheName");
    ...
 }

• Removed release attribute from config object (Atajo 3.0 will be release agnostic - and defined at a domain level)
• Added sourceDomain to fork controller config for addressable lambdas - access through global.sourceDomain in lambda.
• Added auto error response if Lambda throws error (returns tx as failed with stacktrace as data)
• Fixed issue where version detection alerted to update if local version is larger
• Mongo database config details can now be placed in config.json in the lambda directory (This paves the way for adding configs to adjust lambda timeouts, scaling and throughput behaviour)
• Added lambda execution metrics to latency object - e.g.

 "lambdaExecutionTime": {
      "timeToConfigure": "874ms",
      "timeToExecute": "2ms",
      "totalExecutiontime": "161ms",
      "totalAliveTime": "24806ms"
    }