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 :
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 :
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:
var sample = new dbi.samples();
sample.uuid = '1234';
sample.user = 'john';
sample.save().then().catch();
dbi.samples.findOne({uuid:'1234'}).then(result => {...}).catch(error => {...});
dbi.samples.find({user:'peter'}).then(results => {...}).catch(error => {...});
dbi.samples.remove({user:'peter'}).then(result => {...}).catch(error => {...});
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
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
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
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"
}