Neural Processing Mechanisms
Miss any of our Open RFC calls?Watch the recordings here! »


0.7.3 • Public • Published




APX or Apex is no longer maintained and is superseded by Kado.

A new package is available to handle all your JavaScript needs. See for details.

APX API Server

APX (pronounced 'apex') is a non-opinionated, pluggable, modern API server designed to serve multiple communication mediums. The core APX plugins rely on popular community packages such as express, kue,, winston, object-manage to make configuration and two-way communication a breeze.

APX is built to be test friendly out of the box and comes with a testing mode in the configuration that will use mock services and increase testing speed.


Well we have evaluated and contributed to several other API servers and just kept running into deficiencies, such as failure to use a popular library and not light-weight enough.

Thus, we created APX. It's light-weight, uses lots of modern packages, and wires them all together in an extensible stateful environment.


APX can be used homogeneously or through our generator.


$ npm install apx --save


var apx = require('apx')
  console.log('APX is ready!')
//pass options and configure
  cwd: __dirname,
  translators: [''],
  express: {
    routes: [
      {get: {path: '/foo', file: 'actions/foo.js'}}
  'socket-io': {
    enabled: false

actions/foo.js = 'foo'
exports.description = 'Example Foo Action' = function(apx,req,res,next){

Run the application

$ node app

Check the result of the action http://localhost:3000/foo


Our generator is a yeoman generator instance that will scaffold your entire API server.

NOTICE As of 0.6.0 the generator has not been completed yet. We are waiting for the API to solidify before creating the generator. This notice will be removed when the generator has been completed.

//install the generator
$ npm install generator-apx
//scaffold the initial app
$ yo apx
//scaffold a new action (with test)
$ yo apx:action <name>
//scaffold a new helper (with test)
$ yo apx:helper <name>
//scaffold a new initializer
$ yo apx:initializer <name>
//scaffold a new model
$ yo apx:model <name>
//scaffold a new service (with test)
$ yo apx:service <name>
//scaffold a new test (with test)
$ yo apx:task <name>
//scaffold a new translator
$ yo apx:translator <name>


APX consists of several well-known idioms

  • actions
  • helpers
  • initializers
  • middleware
  • models
  • services
  • tasks
  • translators


Actions are the bread and butter of an API server they serve all requests and build responses. Actions are also in charge of firing non-periodic tasks and utilizing services.


Helpers do not get loaded by the APX loading service however helpers are meant to be common modules that assist actions and tasks. Generally these are libraries that augment the req,res variables.


Initializers get executed when the server starts up and are only executed once. These are useful for setting up database connections and loading additional items into the environment.


Middleware is inspired by the idea of Connect Middleware and uses the same principle format.

Middleware is executed before actions are fired and is passed the Request and Response objects for augmentation.

Middleware is also the prescribed location to setup authentication handlers.


Models are optional, but since using models to store data has become so common it seems silly not to support them in context and generators. Models do not get loaded by the APX framework, but can be added during an initializer or per action or task.


Services are just libraries that are treated as singletons. Services should be used to maintain in-memory information, and/or provide access to data providers. Models are services but services are not necessarily models.


Tasks are jobs which are run either periodically or scheduled to run by an action. Tasks are considered headless and while they consume request data. They do not provide response data. They can, however, log using winston.


In other frameworks these are sometimes called "servers". Translators are the middleware that consumes connections and produce generic Request and Response objects. An example of a translator would be an express HTTP server.

Plugin Format

All parts of the structure are implemented in plugins. APX follows a simple plugin format that is similar in all parts of user space. The main APX package only provides the plugin loader and depends on plugins to add functionality to the system. This allows APX to be non-opinionated.

Plugin Verbs / Nouns

There are a couple common verbs used in plugins.

  • run -- Used to execute a function on a call event such as an action or task
  • start -- Used in initializers and translators to start instances / listeners
  • stop -- Used in initializers and translators to stop instances / listeners, and shutdown cleanly
  • pre -- Used in middleware to be executed before the action
  • post -- Used in middleware to be executed after the action

Actions = 'name' //should be concise and match the file name
exports.description = 'description of task' //verbose description for generating maps = function(apx,req,res,next){} //code to be executed by apx and fire the next(err) at the end

Helpers = 'name' //should be concise and match the file name
exports.description = 'description of model' //verbose description for generating maps
exports.helper = {} //object exported by the helper can also be a constructor

Initializers = 'name' //should be concise and match the file name
exports.description = 'description of initializer' //verbose description for generating maps
exports.start = function(apx,next){} //code to be executed to start the initializer, firing next(err) at the end
exports.stop = function(apx,next){} //code to be executed to stop the initializer, firing next(err) at the end

Middleware = 'name' //should be concise and match the file name
exports.description = 'description of middleware' //verbose description for generating maps
//pre only = function(apx,req,res,next){} //constructor function with a prototype for instantiation (for pre run only)
//-- or --
//pre and post
exports.pre = function(apx,req,res,next){} //run this function before the action = function(apx,req,res,next){} //runt this function after the action

Models = 'name' //should be concise and match the file name
exports.description = 'description of model' //verbose description for generating maps
exports.schema = {} //schema used to create the model
exports.model = {} //model object created by desired database software

Services = 'name' //should be concise and match the file name
exports.description = 'description of service' //verbose description for generating maps
exports.service = function(){} //constructor function with a prototype for instantiation

Translators = 'name' //should be concise and match the file name
exports.description = 'description of action or task' //verbose description for generating maps
exports.start = function(apx,next){} //code to be executed to start the translator, firing next(err) at the end
exports.stop = function(apx,next){} //code to be executed to stop the translator, firing next(err) at the end

Tasks = 'name' //should be concise and match the file name
exports.description = 'description of task' //verbose description for generating maps = function(apx,req,next){} //code to be executed by apx and fire the next(err) at the end


Clustering in APX is a breeze. Simply use cluster-master

Here is a quick example


var apx = require('./apx')
  console.log('APX is ready!',apx)
  cwd: __dirname + '/app',
  config: ['config.json'],
  initializers: ['apx-kue'],
  tasks: ['tasks/*.js'],
  translators: ['']
  express: {
    port: 3000


var clusterMaster = require('cluster-master')
  exec: 'app.js',
  env: {NODE_ENV: 'production'},
  repl: {address: '', port: 3002}

To start the cluster simply run

$ node server


APX is an EventEmitter and will emit various actions during its lifecycle that can be used to hook for additional functionality.

NOTE The event emitter for APX is a singleton so be careful when registering events as they may get fired by more than one instance. Thus, its important to use the once operator on a lot of one-off events. Then use the dead event to re-arm.


Fired each time the readyState of the system changes.

var apx = require('apx')
  console.log('APX changed ready state to ' + readyState)

The following ready states are supported.

  • 0 - Dead (not started or stopped)
  • 1 - Ready (completed init and ready to accept operations)
  • 2 - Configured (finished configuring and ready to start)
  • 3 - Starting (before init actions are fired)
  • 4 - Stopping (before shutdown actions are fired)


Fired any time an error occurs.

var apx = require('apx')
  console.log('APX had an error',err)


Fired when configuration and init is completed

var apx = require('apx')
  console.log('APX is ready',instance)

The instance after init is passed to the event.


Fired after shutdown has been completed.

var apx = require('apx')
  console.log('APX has died',instance)

The instance after shutdown is passed to the event.


Fired before running an action.

var apx = require('apx')
  console.log('APX action before',action)

The action object is passed to the event.


Fired after running an action.

var apx = require('apx')
  console.log('APX action after',action)

The action object is passed to the event.


Fired before running a task.

var apx = require('apx')
  console.log('APX task before',task)

The task object is passed to the event.


Fired after running a task.

var apx = require('apx')
  console.log('APX task after',task)

The task object is passed to the event.

NOTE the instance is destroyed after this event.


APX uses object-manage to load and manage configuration data.

This also means the APX instance emits the events from object-manage see below.

object-manage Events



  • Variable testing
  • Default false

Testing mode will use fakeredis as much as possible and will not start listening on any ports. However it will still offer a full featured environment for writing tests. Testing mode will also not start Kue which should not be needed to test tasks.

CWD (current working directory)

  • Variable cwd
  • Default ''

The current working directory is used when loading actions, services, and tasks.


  • Variable initializers
  • Default []

An array of globs or objects or absolute file paths. That should be executed when the server is started.


  • Variable tasks
  • Default []

An array of globs or objects or absolute file paths. That will resolve to tasks.

This must be provided at config time to they can be loaded into Kue and scheduled if needed.


  • Variable translators
  • Default []

An array of globs or objects or absolute file paths. That will resolve to translators that should be started when the server is started

Lifecycle API

The lifecycle functions control how APX is started, stopped and configured.


Pass configuration parameters and instantiate the library. Does not start initializers or translators.

  cwd: __dirname


Starts the APX server by starting initializers and translators. Once that is compelte it fires the ready event which is passed the instance of APX.

  cwd: __dirname
//or for more convenience
  cwd: __dirname

Note If no object is passed to start and setup has not been called APX will throw an exception Tried to start APX without setting it up


Stops the APX server by stopping initializers and translators. Once that is complete it fires the dead event and destroys the instance.

  console.log('APX is now dead')
apx.start({cwd: __dirname})


Restart the APX server by stopping initializers and translators and then restarting them. Stop will fire the dead event. Start will fire the ready event.

  console.log('APX is now dead')
  console.log('APX is now ready')
apx.start({cwd: __dirname})


Reference to the Apx constructor and its prototype. Useful for overriding prototypes before startup.

console.log(apx.Apx.prototype.readyState) //0


The current instance of APX is stored here. This can be use for mocking testing and passing the instance instead of having APX do it manually.

var initializer = require('apx-mongoose')
  console.log('Manually started apx-mongoose')

Note the instance will be null by default when APX has either yet to be started or after being stopped.

Request and Response Objects

In APX the request and response objects create the common layer that translators iterate. They are instances of object-manage and expose all the available methods. These objects, however, are not streams. This is a limitation in some cases but it is the only to make the call stack for middleware usable.

Nearly all API servers implement commands and it is up to the translator to supply any uploaded files which should be written to temporary files using a tool like formidable. After that the action can direct the file to the correct location or transfer it to a storage cluster.

The request and response objects support a file object that points to an incoming temporary file or a file that should be streamed to a file.

If there is a situation where file support is more important than command support then raw stream iteration should be implemented in the translator. It is easy to take existing translators and modify them in userspace.


The request object contains information that is passed along from the request paths from the translator and is supplied in object notation. Thus, req.get('propertyName') is the most common usage to retrieve information. However to allow for the receiving of files there is a req.files array that shall be populated with files that were written to temporary files during the request.

In order to access parts of the translator for more control over specific access mediums like the HTTP server the raw request object shall be provided via req.raw

Example = 'myAction'
exports.description = 'Example Action' = function(apx,req,res,next){
  req.get('foo') //bar //bar

Add File

As a convenience for translators to add files to the request object the addFile() method exists.


var req = new Request()


The response object is built by the action and middleware which is then passed on to the user through the translators desired output format. In most cases the output format is JSON but this is sometimes configurable at the translator level.

Add Body Content

To allow the sending of raw data rather than JSON or any other format that can be transformed from an object the add() method comes in handy.

Example = 'myAction'
exports.description = 'Example Action' = function(apx,req,res,next){
  res.add('content to show')
  res.add('more content to show')


As a convenience method success() exists to signal success to the client. This method uses a standard response format. That resembles the following. Success also accepts a few argument combinations to allow more structured responses without additional function calls.


{"status": "ok", "message": "success", "code": "0"}

Example = 'myAction'
exports.description = 'Example Action' = function(apx,req,res,next){
  res.success() //sends message: 'success', code: '0'
  res.success('foo') //sends message: 'foo', code: '0'
  res.success('foo',4) //send message: 'foo', code: '4'
  res.success('foo',4,{id: 'bar'}) //sends message: 'foo', code: '4', id: 'bar'
  res.success('foo',{id: 'bar'}) //sends message: 'foo', code: '0', id: 'bar'
  res.success({id: 'bar'}) //sends message: 'success', code: '0', id: 'bar'


For easier error handling the error method can be used to pass an erroneous response to the client and accepts a few different combinations of arguments to supply the user with information about the error.


{"status": "error", "message": "error", "code": "1"}

Example = 'myAction'
exports.description = 'Example Action' = function(apx,req,res,next){
  res.error() //sends message: 'An error has occurred', code: '1'
  res.error('foo') //sends message: 'foo', code: '1'
  res.error('foo',4) //send message: 'foo', code: '4'
  res.error('foo',4,{id: 'bar'}) //sends message: 'foo', code: '4', id: 'bar'
  res.error('foo',{id: 'bar'}) //sends message: 'foo', code: '1', id: 'bar'
  res.error({id: 'bar'}) //sends message: 'An error has occurred', code: '1', id: 'bar'

Send File

Sometimes it is useful to send clients a file thus the sendFile(path) method exists. This will notify the translator that a file should be sent to the user and allows the translator to properly handle streaming the file to the user.

When a file by that path cannot be found it will throw an exception.

NOTE Whenever this method is called it will supersede any other output that has been queued to be sent to the user by using add() or set(). Unless the translator is capable of sending multipart responses.

Example = 'myAction'
exports.description = 'Example Action' = function(apx,req,res,next){
  res.sendFile('/tmp/foo','home.html',{tmpFile: true}) //setting tmpFile to true will delete the file after sending


In order for translators to properly handle sending data to their clients there are 3 scenarios which apply to how the render function will respond.

  • format this is the format of the response which will be object, raw, or file
  • mimeType the detected or manually set mime type of the response should be used to respond in various formats when using the object type.
  • body this is the content container for the raw format
  • data this is the content container for the object format and contains the data object to be exported
  • file this is a reference to the file object when using the file format


In this example the output will simply be logged to the console.

var xml = require('xml')
  , fs = require('fs')
  , Response = require('apx/lib/Response')
  , res = new Response()
//create our response handler
var responseHandler = function(err,response){
  if(err) throw err
  if('object' === response.format){
    if('text/json' === response.mimeType){
    } else if('text/xml' === response.mimeType){
    } else {
      console.warn('desired output type of ' + response.mimeType + ' is not supported defaulting to JSON')
  } else if('raw' === response.format){
  } else if('file' === response.format){
    var stream = fs.createReadStream(response.file.path)
      var chunk
      while(null !== (chunk ={
  } else {
    console.warn('desired output format of ' + response.format + ' is not supported, not sending output')
//implement the handler



  • Fixed #5 where the post chain is broken by legacy middleware.


  • Changed the way runAction and runTask populate the request to prevent object merging issues


  • Upgraded to object-manage 0.7.0 which changes how the constructor and load accept arguments
  • APX, Request, and Response all inherit the changed constructor functionality of object-manage


  • Added support for charsets in Response object
  • Changed the default mimeType from text/json to application/json
  • Fixed small bug with passing arrays to runAction and runTask as data


  • Request objects now implement the file object
  • Response objects now implement the file object
  • Response.send() removed in favor of the existing object-manage functions
  • In order to support pre and post middleware translators need to fire the Response.render() method and then send the rendered response to their client
  • Upgraded middleware, model, service and helper plugin format. This will require upgrading of existing plugins and makes this version incompatible with older plugins.
  • Added Response.sendFile(path) to allow sending of files to the user. Using this method still requires calling next() and will supersede any existing output.
  • Improved Response.success() and Response.error() to accept a better combination of arguments to produce usable responses with a single function call.


  • Implementation of APX authentication system #3
  • APX now loads packages exactly like Node's require(). Except for the addition of parsing globs. see this
  • Middleware now supports pre and post actions with a default of run which will be fired before the action.


  • Usage no longer involves new Apx the returned object is now an event emitter
  • Changed lifecycle management and abstract usage of the APX library. This changes usage of APX and will require upgrading.
  • SysLog added for core level logging. Winston should be used for user-space logging.
  • Kue removed from core package and abstracted to apx-kue
  • Winston removed from core package and abstracted to apx-winston
  • Tasks are no longer initialized by the core should be implemented in an initializer
  • Updated plugin format (this means existing initializer/translator/service plugins will need to upgrade) see the README for the prescribed plugin format.
  • Added 'use strict'; statements to all files and removed testing init file
  • APX is now an event emitter and onReady has been removed see README for events
  • Response object no longer accepts a callback and actions should fire next explictly with any errors. See plugin format in the README for details.
  • Added the idea of middleware that is executed in order before each action process.


  • Updated to object-manage 0.4.0
  • Restored and as references to the managed objects.
  • Fixed issue with tasks being passed the entire job object instead of


  • Updated to object-manage 0.3.0


  • Final fix for redis in testing mode


  • Fixed using real redis during testing mode


  • Fixes #2 - Objects are now disallowed from being passed to the config
  • Loading framework now more async friendly
  • Init is handled completely async
  • Fixed minor issue with Response object not rendering JSON properly
  • Removed unused dependencies
  • Updated object-manage upstream


  • Fixes #1 - Fails when loading required translator


  • Dropped convict in favor of object-manage


  • Initial release


npm i apx

DownloadsWeekly Downloads






Unpacked Size

107 kB

Total Files


Last publish


  • avatar