wgu-servicelayer

0.1.10 • Public • Published

wgu-servicelayer

Node.js REST/JSON service layer framework that runs on top of Heroku used by Western Governors University.

NPM

Basic Usage

var server = require('wgu-servicelayer');
 
server.get('/hello/:name', function(req, res) {
    res.send('Hello ' + req.params.name, 300);
});
 
server.getWithoutCache('/goodbye/:name', function(req, res) {
    res.send('Goodbye ' + req.params.name);
});
 
server.listen(3000);

This service layer framework uses restify, redis, and soap Node.js packages and extends the functionality by adding WGU specific configuration for use on desktop machines during development with final code deployment to the Heroku cloud service. The above code registers two REST/JSON endpoints with the GET HTTP method. The server variable makes the three modules used in this framework available through a single variable interface.

Restify's method registration methods (get, post, put, delete, patch, option, head) are exposed through the wgu-servicelayer module. Additional capability has been added to surround the get method to auto cache JSON response to a Redis memory cache. The send function passed into the regular get function takes a second parameter that the restify version does not take which is the number of seconds to hold the object response in the memory cache server. Passing no second parameter will cause the result to not be cached. A function has been added that will register a HTTP GET method endpoint directly with the restify module without checking for a stored value in the memory cache. The getWithoutCache function will utilize restify only functionality avoiding the customizations added by the new get method.

The listen function activates the server and takes port parameter. This parameter is ignored if an environment variable of process.env.PORT exists. In this framework, Heroku environment variables are always preferred over values set in code. On a development machine, the port would be 3000 in this example but when deployed to Heroku, the port will be whatever the cloud instance designates

Because the server is registered in the wgu-servicelayer module, the server functions are available to any other module so endpoint registration does not need to occur in the main script file.

/app.js

var server = require('wgu-servicelayer');
 
// Service Modules
require('./mymodule');
require('./services/mymodule2');
 
server.listen();

/mymodule.js

var server = require('wgu-servicelayer');
 
server.get('/hello/:name', function(req, res) {
    res.send('Hello ' + req.params.name, 300);
});

/services/mymodule2/index.js

var server = require('wgu-servicelayer');
 
server.get('/hello2/:name', function(req, res) {
    res.send('Hello ' + req.params.name, 300);
});

Heroku Environment Variables

Basic Authentication

  • SERVICE_CLIENT_USER
  • SERVICE_CLIENT_PASSWORD

Redis Memory Caching (Setup by adding plugin to Heroku instance)

  • REDISCLOUD_URL
  • REDISTOGO_URL
  • OPENREDIS_URL
  • REDISGREEN_URL

Global SOAP Credentials for Service

  • SOAP_CLIENT_USER
  • SOAP_CLIENT_PASSWORD

Iron MQ (Setup by adding plugin to Heroku instance)

  • IRON_MQ_PROJECT_ID
  • IRON_MQ_TOKEN

Endpoint Security

Current security for all endpoints is temporarily handled by Basic Authentication. This functionality is not engaged unless a environment variable of SERVICE_CLIENT_USER and SERVICE_CLIENT_PASSWORD are set. Once engaged these values are used during the development stage of this framework. This is a temporary only measure and is not the final version. This functionality will be expanded to include code or environment level configuration of other passport security strategies.

Memory Caching

WGU uses the a redis service through Heroku but may be changed out in the future. If the environment variable does not exist, then the memory caching functionality is ignored. The variable will be added on the Heroku instance when the Redis Cloud plugin is added. If the environment variable does not exist, the url can be overridden in code by calling the startCache method.

server.startCache(process.env.OTHER_REDIS_SERVER_URL);

SOAP Client and WS Security

The soap package is used to read a WSDL and generate a SOAP client for use in the application. On startup the WSDL folder at the base of your application will be read, all WSDL files located there will be processed into a client and made available through the server.soap.clients variable. The client can then be accessed in your code and methods called against.

var server = require('wgu-servicelayer');
 
server.get('/:version/person/:id/info', function(req, res){
    
    if (req.params.version === '1'){
        var client = server.soap.clients.NAME_OF_WSDL_FILE;
        
        client.MyOperation({id: req.params.id}, function(err, result){
            if (err) {
                console.log(err);
                res.send(err);
            } else {
                res.send(result.Response, 300);
            }
        });        
    }
});

SOAP services provided internally by WGU will be available to the API service layer. Each service layer application will have its own log in credentials and will be set via environment variables SOAP_CLIENT_USER and SOAP_CLIENT_PASSWORD. Setting these values will automatically place the WS Security setup on all generated SOAP clients.

Message Queue

To support web to worker process communication, Iron MQ will be used. After adding the add on to your Heroku application, use the following code to get a client.

var server = require('wgu-servicelayer');
 
server.setupMessageClient('my_queue_name');
 
server.iron.client.my_queue_name.post('My message', function(err, body) {
   // validate the response
});

Then use the API like normal.

https://devcenter.heroku.com/articles/iron_mq#node-js

Readme

Keywords

none

Package Sidebar

Install

npm i wgu-servicelayer

Weekly Downloads

0

Version

0.1.10

License

none

Last publish

Collaborators

  • joseph.lindley.wgu