getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details

Copyright © 2016 M/Gateway Developments Ltd
EWD 3 Training Course
Part 45
Using QEWD's Advanced
MicroService Functionality
Rob Tweed
Director, M/Gateway Developments Ltd
Twitter: @rtweed

Using QEWD's Advanced
MicroService Functionality
• This part of the course assumes that
you've taken, at least:
• Part 31: Using QEWD for Web and REST
Services
• http://www.slideshare.net/robtweed/ewd-3-training-course-part-31-ewdxpress-for-web-and-rest-services
• Part 43: Using JSON Web Tokens with QEWD
REST Services
– https://www.slideshare.net/robtweed/ewd-3-training-course-part-43-using-json-web-tokens-with-qewd-rest-services
• Part 44: Creating MicroServices with QEWD.js

MicroServices: Background
• For an introduction on MicroServices,
what they are, how they work and when
and why they should be considered, see
this overview on QEWD.js and
MicroServices:
• https://www.slideshare.net/robtweed/qewdjs-json-web-tokens-microservices

QEWD MicroService Fabric
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Demographics
Pharmacy
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Client Orchestration
HTTPS
WebSocket
Connections

QEWD.js Solution
ewd-qoper8
queue
Express
Node.js
socket.io
Equivalent to
ewd-client
socket.io-client
Incoming REST
request

QEWD.js Solution
ewd-qoper8
queue
Express
Node.js
socket.io
Equivalent to
ewd-client
socket.io-client
Incoming
WebSocket
request

QEWD.js Solution
ewd-qoper8
queue
Express
Node.js
socket.io
Equivalent to
ewd-client
socket.io-client
Incoming
WebSocket
request
Process
Locally?

QEWD.js Solution
ewd-qoper8
queue
Express
Node.js
socket.io
Equivalent to
ewd-client
socket.io-client
Incoming
WebSocket
request
Handled
by remote
MicroService?

QEWD.js Solution
ewd-qoper8
queue
Express
Node.js
socket.io
Persistent
Bi-directional
WebSocket
connection
Secured
over
HTTPS
ewd-qoper8
queue
Express
Node.js
socket.io
Equivalent to
ewd-client
socket.io-client
Remote QEWD MicroService

QEWD MicroService Architecture
• Incoming requests can be either from:
– a browser over WebSockets or Ajax
– REST over HTTP / HTTPS
• This tutorial will focus on REST

Advanced QEWD
MicroServices
• In this Part of this course, we'll look at the
advanced MicroServices features of QEWD,
including:
– Templated routes
– Dynamic path-defined destinations
– Federated composite MicroServices from a group of
destinations
– Re-direction of MicroService responses to another
MicroService
– Chained MicroServices

Example in Part 44
• In the previous part of this course we set
up an example with:
– A primary server
• One local service: /api/info
– A Login MicroService server
• One MicroService: /api/login
• /api/info could not be run until /api/login
had been run, and its returned JWT used
in the Authorization Header

Example in Part 44
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Client Primary Server
HTTPS
WebSocket
Connections
Login MicroService Server

Advanced MicroService Functionality
• To demonstrate the advanced MicroService
Functionality, we'll extend the examples used in Part 44
• Primary Server:
– Startup file: ~/qewd/ms-startup.js
– Local REST services:
• ~/qewd/node_modules/myLocalServices
• Login MicroService Server:
– Startup file: ~/qewd/loginservice.js
– MicroService Handler Module:
• ~/qewd/node_modules/login-micro-service.js

Advanced MicroService Functionality
• To demonstrate the advanced MicroService
Functionality, we'll extend the examples used in Part 44
• In the example code, I'll assume the host addresses for
the servers are:
– Primary Server: 192.168.1.120:8080
– Login MicroService Server: 192.168.1.121:8080
• Adjust these to match your servers

Templated Routes
• In part 44, the login MicroService route
was defined in the Primary Server's
startup file using an absolute route:
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
application: 'login-micro-service'
}
},
routes: [
{
path: '/api/login',
method: 'POST',
destination: 'login_service'
}
]
}
};

Templated Routes
• Just as with QEWD's REST routing, your
MicroService Routes can define variable
components, eg:
routes: [
{
path: '/api/patient/:patientId/demographics',
method: 'GET',
destination: 'login-micro-service'
}
]

Templated Routes
• Templated Routes can contain any
number of variable parts, eg:
routes: [
{
path: '/api/patient/:patientId/headings/:headingName/info',
method: 'GET',
destination: 'login-micro-service'
}
]

How Templated Routes Work
• The message sent to the MicroService will
contain:
– The actual path that was used
– The path template that it matched
– The values of the variable path components,
as name/value pairs

• For example, if the specified route is
routes: [
{
method: 'GET',
destination: 'patientInfo_service'
}
]

• and the actual request was:
– /api/patient/123456/headings/allergies/info
routes: [
{
method: 'GET',
}
]

• and the actual request was:
– /api/patient/123456/headings/allergies/info
• Message to MicroService will include:
– Path: /api/patient/123456/headings/allergies/info
– Matched Template Path: /api/patient/:patientId/headings/:headingName/info
– Parameters: {patientId: 123456, headingName: 'allergies'}
routes: [
{
method: 'GET',
}
]

Example primary Server Startup File (1)
var config = {
managementPassword: 'keepThisSecret!',
serverName: 'New QEWD Server',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
secret: 'someSecret123'
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
Note that both routes
have the same
destination

Example primary Server Startup File (2)
var routes = [
{
path: '/api',
module: 'myLocalServices',
errors: {
notfound: {
text: 'Resource Not Recognised',
statusCode: 404
}
}
}
];
var qewd = require('qewd').master;
var q = qewd.start(config, routes);

Handling Templated Routes on
MicroService Server
• Define the templated route in your Worker
Process Handler module, eg
– ~/qewd/node_modules/login-micro-service.js

MicroService Server
• Define the templated route in your Worker
Process Handler module, eg
init: function() {
routes = {
'/api/login': {
POST: login
}
};
router.addMicroServiceHandler(routes, module.exports);
}
This is what we'd created in Part 44 when we
defined the login MicroService

MicroService Server
init: function() {
routes = {
'/api/login': {
POST: login
},
' /api/patient/:patientId/demographics ': {
GET: getDemographics
}
};
}
Add the new templated route definition

MicroService Server
init: function() {
routes = {
'/api/login': {
POST: login
},
}
};
}
Specify the route template exactly the same as
on the primary server

MicroService Server
init: function() {
routes = {
'/api/login': {
POST: login
},
}
};
}
So how will the handler function – getDemographics()
in our example here – handle the variable path?

MicroService Server
function getDemographics(args, finished) {
var patientId = args.patientId;
// ..etc
}
The values of variable path components are
automatically made available to you as properties
of the args object
It's identical to handling variable routes in standard
QEWD REST services (see Part 31)

MicroService Server
var patients = {
'123456': {
firstName: 'Rob',
lastName: 'Tweed',
gender: 'Male',
country: 'UK'
},
'123457': {
firstName: 'Jane',
lastName: 'Smith',
gender: 'Female',
country: 'USA'
},
};
var patientId = args.patientId.toString();
if (!patientId || patientId === '') {
return finished({error: 'You must specify a patientId'});
}
if (!patients[patientId]) {
return finished({error: 'Invalid patientId'});
}
finished(patients[patientId]);
}
For example:
hard-coded simulation of
a patient database

Example MicroService Module (1)
var router = require('qewd-router');
var routes;
function login(args, finished) {
var username = args.req.body.username;
var password = args.req.body.password;
var session = args.session;
if (username === 'rob' && password === 'secret') {
session.userText = 'Welcome Rob';
session.username = username;
session.authenticated = true;
session.timeout = 1200;
session.makeSecret('username');
session.makeSecret('authenticated');
return finished({ok: true});
}
else {
return finished({error: 'Invalid login'});
}
}

module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
},
'/api/patient/:patientId/demographics': {
}
};
}
};

Try it
• Stop and restart the startup files on the
Primary and MicroService servers
• In your REST Client:
– GET /api/patient/1234567/demographics

Try it

Try it
It successfully returned the results for patient 123457
Try changing the patientId in the path to 123456

Security Issue
• We have a problem – the demographics
MicroService can be invoked by anyone
• It should only be accessible if you've
logged in using the Login MicroService
• We can fix this by adding a
beforeMicroServiceHandler() function into
the MicroService module

module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
},
}
};
},
beforeMicroServiceHandler: function(req, finished) {
// authenticate against the JWT (except for Login requests)
if (req.path !== '/api/login') {
return this.jwt.handlers.validateRestRequest.call(this, req, finished);
}
}
};

module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
},
}
};
},
}
}
};
Ignore Login requests – no JWT needed for them

module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
},
}
};
},
}
}
};
This is the same API that we used in the previous
Part of the course. There we applied it to the
beforeHandler() function of the Local REST Service Module

Try it
• Now you should get an error:
• Authorization Header missing or JWT not found in
header (expected format: Bearer {{JWT}}

Try it
• OK so try logging in:
– POST /api/login
• {"username": "rob", "password": "secret"}
• If it logged you in successfully, copy the
returned JWT into the Authorization
Header:
• Authorization: Bearer {{JWT}}

Try it
• Now try the Demographics request again
• Now it should work
• Only logged in users can invoke the
demographics request

MicroService Server
init: function() {
routes = {
'/api/login': {
POST: login
},
' /api/patient/:patientId/headings/:heading/summary ': {
GET: getHeadingSummary
}
};
}
A path can include as many variable components
as you require. Here, we have :patientId and
:heading

MicroService Server
function getHeadingSummary(args, finished) {
var patientId = args.patientId;
var heading = args.heading;
// ..etc
}
The values of variable path components are
automatically made available to you as properties
of the args object

Dynamic Routes

Dynamic Routes
• So far, our examples have used fixed
destinations:
– A URL route is tied to a specific destination,
eg: u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}

Dynamic Routes
• You can also have dynamic routes
• :destination is a reserved URL path
component name
• It's mapped at run-time to the destination
actually specified in the URL, and the
request is routed to that physical
destination

Dynamic Routes
• For example, suppose we have several
stores, and we want to retrieve a list of
items in stock at a particular store

Dynamic Routes
• Define the store destinations in the
primary server's startup configuration:
u_services: {
destinations: {
store1: {
host: 'http://store1.retailer.com:8080',
application: 'stock-list'
},
store2: {
},
store3: {
}
}
}

Dynamic Routes
• Then define the route with the variable
destination:
u_services: {
destinations: {
//
},
routes: [
{
path: '/api/store/:destination/stocklist',
method: 'GET'
}
]
}

Dynamic Routes
• Each store would have the stock-list
application module installed:
var routes;
function getStockList(args, finished) {
// collate the stock list for the store
var stockListObj = {
stock: 'stock list here...'
};
finished(stockListObj);}
module.exports = {
init: function() {
routes = {
'/api/store/:destination/stocklist': {
GET: getStockList
}
};
}
};

Dynamic Routes
• Each store would have the stock-list
application module installed:
var routes;
};
finished(stockListObj);}
module.exports = {
init: function() {
routes = {
GET: getStockList
}
};
}
};
URL path must be
specified identically
to primary server's
route

Dynamic Routes
• The client then specifies the URL:
– GET /api/store/store2/stocklist
– In this case, the request will be routed to the
destination named store2

Dynamic Routes
• The URL route can include other variable
components, eg
• The handler function getStockListByCategory()
would access the category using args.category
routes = {
'/api/store/:destination/category/:category/stocklist': {
GET: getStockListByCategory
},
}

Adding Security
• Our earlier example included a Login
MicroService on a server specifically for
user authentication
• We've now added 3 stores as additional
locations
• We'll want to make sure that the stores
can't be interrogated until the user has
logged in

Adding Security
• Just add the beforeMicroServiceHandler()
function to the handler module in each of
the stores:
}
Every incoming request to each store will now need a valid
JWT that originated from a valid Login

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Expre
ss
Nod
e.js
socke
t.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Store 1
Store 2
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
ewd-qoper8
queue
Express
Node.j
s
socket.i
o
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Store 3

Grouped Destinations

Grouped Destinations
• In the previous example, you requested
the stock list from a single store that you
specified
• What if you wanted to get a combined
stock listing from all stores?
• That's where Grouped Destinations can
be used

Setting up a Group Destination
• On the primary server:
– Define the destination and any routes using
the group destination
• On the servers within the group
destination:
– Define the route(s) within the application
module

Primary Server
• Within the startup file configuration:
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
},
store1: {
host: 'http://192.168.1.114:8080',
},
store2: {
host: 'http://192.168.1.119:8080',
},
allStores: {
destinations: ['store1', 'store2']
}
},
routes: [
]
}

Primary Server
• Within the startup file configuration:
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
},
store1: {
host: 'http://192.168.1.114:8080',
},
store2: {
host: 'http://192.168.1.119:8080',
},
allStores: {
}
},
routes: [
]
}
We're defining a new destination
named allStores which is a group
consisting of store1 and store2,
each of which must be separately
defined

Primary Server
• Now define any routes for this group:
u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET'
},
{
path: '/api/store/:destination/category/:category/stocklist',
method: 'GET'
},
{
path: '/api/all/stocklist',
method: 'GET',
destination: 'allStores'
}
]
}

On each Server in the Group
• Define route(s) in the application module
init: function() {
routes = {
GET: getStockList
},
},
'/api/all/stocklist': {
GET: getStockList
}
};
},

On each Server in the Group
• Define route(s) in the application module
init: function() {
routes = {
GET: getStockList
},
},
'/api/all/stocklist': {
GET: getStockList
}
};
},
In this example, we'll just re-use the getStockList()
function that we previously defined

Security / Authentication
• We've already added the
beforeMicroServiceHandler() function, so
you'll have to first login before you can use
the new Grouped destination request.
}

Try it
– GET /api/all/stocklist
• You should see activity on all machines,
but you should get an error:
• Authorization Header missing or JWT not found in
header (expected format: Bearer {{JWT}}

Try it
• Now try again:
– GET /api/all/stocklist
• This time you should get a composite
result back from your store MicroServices
– Remember that we asked to run the same
getStockList function as before on each store
MicroService

Try It

Try It
Each store's results appears
within a results object,
identified by each destination's
name

Try It
Response format for all
Grouped destinations
{results:
destination1: {results object},
destination2: {results object},
…etc
}

Try It
A new JWT with updated
expiry is also returned

Dynamic Grouped Destination?
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
},
store1: {
host: 'http://192.168.1.114:8080',
},
store2: {
host: 'http://192.168.1.119:8080',
},
allStores: {
}
},
routes: [
]
}
Our grouped destination – allStores – is
still just a destination.

Dynamic Grouped Destination?
u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET'
},
{
method: 'GET'
},
{
method: 'GET',
}
]
}
So what happens if
we use it for this route?

Try It
Almost identical results as
before!
A composite result from each
destination within the group
Is returned

Try It
If you look carefully, there is
a small difference. This time
each store returns a store
property with a value of
allStores.

Try It
That's because the getStockList()
function that ran on each store
returned the value of
args.destination
store: args.destination,
ip: '192.168.1.119',
};
finished(stockListObj);
}

Try It
That's because the getStockList()
function that ran on each store
returned the value of
args.destination
:destination was defined in the
dynamic route that we just used,
but not in the /api/all/stocklist route
we used previously
ip: '192.168.1.119',
};
finished(stockListObj);
}

Custom Response Handling

• So far we've let QEWD automatically
return the responses to the REST client

• What if you want to do something with the
response before it's returned?

• What if you want to do something with the
response before it's returned, eg:
– Re-packaging / re-formatting of the response
– Conditional behaviour depending on the
response content
– Triggering a new request to another
MicroService

• Each route that you define in your Primary
server's startup file can have an optional
additional property:
– onResponse

• Each route that you define in your Primary
server's startup file can have an optional
additional property:
– onResponse
• You define a function to handle the response
• The function has a single argument, args, that
contains all you need to handle the response

u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET'
},
{
method: 'GET'
},
{
method: 'GET',
}
]
}
Here's our routes as
defined in the Primary
Server's startup file

u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET'
},
{
method: 'GET'
},
{
method: 'GET',
}
]
}
We'll add custom handling
to this one

u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
onResponse: function(args) {
console.log('** onResponse: ' + JSON.stringify(args));
}
},
{
method: 'GET'
},
{
method: 'GET',
}
]
}
Let's initially just inspect
that args object

Try it
• First log in:
– POST /api/login
• {"username": "rob", "password": "secret"}
• If it logged you in successfully, copy the
returned JWT into the Authorization
Header:
• Authorization: Bearer {{JWT}}

Try it
• Now send this request:
• Now look in the Node.js console log for
your Primary server

onResponse args Object
received: {"type":"restRequest","finished":true,"message":{"store":"store1","ip":"192.168.1.114","stock":"stock list
here...","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDQwODQ0NzcsImlhdCI6MTUwNDA4MzI3NywiaX
NzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6InN0b2NrLWxpc3QiLCJ0aW1lb3V0IjoxMjAwLCJxZXdkIjoiZmU3NDYwYTNmYz
hhZjFmOWI4ZTFmNTFkNjNhYWM1N2Q3OTNkYzk1NmJiYWQ0YThjZGZiNDBhODE5OTc5NmE3ODNjMGJkZjJmNDIxZWU2
YzU3Y2Q1MjIxOGYwNTE3MTRlMTE1YjRiYTI1NjhhMzY0MmRjNDVjYWY5Y2I4MDIzNmYzNDNkNGFiOTJhODM1OWU2YTQ
0YzRmZTU2MmUzNjRhNGYyYzkwZjhkY2Y3ODIzM2I5N2NkOTA0OGZkZDM1NGY0NzJmMmU2YTk4Y2ZiNmU1MTBkMGI3
MTVkIiwidXNlclRleHQiOiJXZWxjb21lIFJvYiJ9.yAxPEOHRPWsBc7jNDfq_Rul-
VCOSOchRAAD0Vqmbs1o"},"responseTime":"8ms"}
** onResponse: {"message":{"type":"ewd-qoper8-express","path":"/api/store/store1/stocklist","method":"GET","headers":
{"host":"192.168.1.120:8080","authorization":"Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDQwODQ0NDQsImlhdCI6MTUwNDA4MzI0NCwiaXNzIjoicWV3ZC5
qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0IjoxMjAwLCJxZXdkIjoiZmU3NDYwYTNmYzh
hZjFmOWI4ZTFmNTFkNjNhYWM1N2Q3OTNkYzk1NmJiYWQ0YThjZGZiNDBhODE5OTc5NmE3ODNjMGJkZjJmNDIxZWU2Y
zU3Y2Q1MjIxOGYwNTE3MTRlMTE1YjRiYTI1NjhhMzY0MmRjNDVjYWY5Y2I4MDIzNmYzNDNkNGFiOTJhODM1OWU2YTQ0
YzRmZTU2MmUzNjRhNGYyYzkwZjhkY2Y3ODIzM2I5N2NkOTA0OGZkZDM1NGY0NzJmMmU2YTk4Y2ZiNmU1MTBkMGI3M
TVkIiwidXNlclRleHQiOiJXZWxjb21lIFJvYiJ9.8pY7HEBIdhWZEXR0WBeIJBGEgn-WpRwcwDZf-0uJ0AM","content-
type":"application/json"},"params":{"0":"store1/stocklist","type":"store"},"query":{},"body":{},"ip":"::ffff:192.168.1.74","ips":
[],"application":"api","expressType":"store"},"destination":"store1","responseObj":
{"type":"restRequest","finished":true,"message":{"store":"store1","ip":"192.168.1.114","stock":"stock list
here...","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDQwODQ0NzcsImlhdCI6MTUwNDA4MzI3NywiaX
NzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6InN0b2NrLWxpc3QiLCJ0aW1lb3V0IjoxMjAwLCJxZXdkIjoiZmU3NDYwYTNmYz
hhZjFmOWI4ZTFmNTFkNjNhYWM1N2Q3OTNkYzk1NmJiYWQ0YThjZGZiNDBhODE5OTc5NmE3ODNjMGJkZjJmNDIxZWU2
YzU3Y2Q1MjIxOGYwNTE3MTRlMTE1YjRiYTI1NjhhMzY0MmRjNDVjYWY5Y2I4MDIzNmYzNDNkNGFiOTJhODM1OWU2YTQ
0YzRmZTU2MmUzNjRhNGYyYzkwZjhkY2Y3ODIzM2I5N2NkOTA0OGZkZDM1NGY0NzJmMmU2YTk4Y2ZiNmU1MTBkMGI3
MTVkIiwidXNlclRleHQiOiJXZWxjb21lIFJvYiJ9.yAxPEOHRPWsBc7jNDfq_Rul-
VCOSOchRAAD0Vqmbs1o"},"responseTime":"8ms"}}

onResponse args Object{
"message": {
"type": "ewd-qoper8-express",
"path": "/api/store/store1/stocklist",
"method": "GET",
"headers": {
"host": "192.168.1.120:8080",
"authorization": "Bearer eyJ0eXAiOiJKV1..",
"content-type": "application/json"
},
"params": {
"0": "store1/stocklist",
"type": "store"
},
"query": {},
"body": {},
"ip": "::ffff:192.168.1.74",
"ips": [],
"application": "api",
"expressType": "store"
},
"destination": "store1",
"responseObj": {
"type": "restRequest",
"finished": true,
"message": {
"store": "store1",
"ip": "192.168.1.114",
"stock": "stock list here...",
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI..."
},
"responseTime": "8ms"
}
}
Let's prettify the args
Object, so we can
see what it contains

{
"message": {
"type": "ewd-qoper8-express",
"path": "/api/store/store1/stocklist",
"method": "GET",
"headers": {
"host": "192.168.1.120:8080",
"authorization": "Bearer eyJ0eXAiOiJKV1..",
"content-type": "application/json"
},
"params": {
"0": "store1/stocklist",
"type": "store"
},
"query": {},
"body": {},
"ip": "::ffff:192.168.1.74",
"ips": [],
"application": "api",
"expressType": "store"
},
args.message:
-The original incoming
request object

{
"destination": "store1",
}
args.destination:
-Any variable path components
will be available as properties
in their own right.
So the value of :destination in
our request is available to us

{
"responseObj": {
"type": "restRequest",
"finished": true,
"message": {
"store": "store1",
"ip": "192.168.1.114",
"stock": "stock list here...",
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI..."
},
"responseTime": "8ms"
}
}
args.responseObj:
-The raw response object
that was returned from
the MicroService

• It also contains two other properties that
aren't shown, as they are functions:
– args.handleResponse
– args.send

• If you want to re-package / re-format the response,
you must use this function to return your response
to the REST client.
– args.send

– args.send
• If you want to send a request to another
MicroService, you use this function

– args.send
• Note: if you use either of these functions,
your onResponse() function MUST return
true. This tells QEWD not to try to handle
the response itself

Custom Response Example
u_services: {
destinations: {
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
console.log('** onResponse: ' + JSON.stringify(args));
}
},
{
method: 'GET'
},
{
method: 'GET',
}
]
}
Let's return our own
custom response…

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
if (!args.responseObj.message.error) {
var respObj = {
youSent: args.message.path,
usingMethod: args.message.method,
toStore: args.destination,
stock: args.responseObj.message.stock
};
args.handleResponse(respObj);
return true;
}
}
}
]
}

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
If an error has occurred,
we'll let QEWD handle it

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
Otherwise, we'll
create our own
response object
from information in
the args object

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
Use the handleResponse()
function to return the
response to the REST
client

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
And finally tell QEWD
that we've handled the
response ourselves, so
it doesn't need to

Try It
• Remember to first log in

Try It
There's our re-packaged
custom response

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
One thing to remember:
Your onResponse() function
is invoked in the QEWD
Master process

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
So make sure you don't
do anything CPU-intensive
or long-running

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
You should consider running
your logic in a QEWD worker
process.
If you do, you'd also have
access to the database

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var respObj = {
};
return true;
}
}
}
]
}
But how do you use a
QEWD Worker Process
from here?
It's actually very easy…

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var msg = {
type: 'save',
token: args.responseObj.message.token,
jwt: true
};
}
}
}
]
}
First we create a message object
It must contain at least these 3
properties.
The value of type is up to you, but
use the values shown for token
and jwt

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var msg = {
type: 'save',
jwt: true,
params: {
path: args.message.path,
method: args.message.method,
}
};
}
}
}
]
}
Now we'll add the data we
want to send to the Worker
in our message

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var msg = {
type: 'save',
jwt: true,
params: {
}
};
this.handleMessage(msg, function(responseObj) {
args.handleResponse(responseObj);
});
}
}
}
]
}
this.handleMessage() is the ewd-qoper8
API for sending a message to a Worker.
Its callback allows us to process the
response from the Worker – we'll send
the response to the REST client, using
args.handleResponse()

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var msg = {
type: 'save',
jwt: true,
params: {
}
};
});
return true;
}
}
}
]
}
Finally, tell QEWD that we're
Handling the response

Try It
• Login and put the JWT into the
Authorization header as before
• Then send:
• You should get back an error:
{"error": "Unable to load handler module for: stock-list"}

Why That Error?
• It was expected that we'd get an error
back from the QEWD Worker process
– We haven't yet written a handler function for
the message type we sent to it

Why That Error?
• But the error was because it couldn't find a
module named stock-list
– Why was it looking for a module of this name?

Why That Error?
• But the error was because it couldn't find a
module named stock-list
– Why was it looking for a module of this name?
• It's because we sent the JWT as the
message token

u_services: {
destinations: {
},
routes: [
{
method: 'GET',
var msg = {
type: 'save',
jwt: true,
params: {
}
};
});
return true;
}
}
}
]
}
We sent the JWT that was returned
by the MicroService

Time to Inspect the JWT
u_services: {
destinations: {
},
routes: [
{
method: 'GET',
console.log('** token: ' + args.responseObj.message.token);
var msg = {
type: 'save',
jwt: true,
params: {
}
};
});
return true;
}
}
}
]
}
We'll display the token in the
Node.js console log

• Restart QEWD on the Primary server and
try sending that same request
• Then take a look in the Node.js console
log

** token:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDQwOTQwNjcsImlhd
CI6MTUwNDA5Mjg2NywiaXNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6InN0
b2NrLWxpc3QiLCJ0aW1lb3V0IjoxMjAwLCJxZXdkIjoiZmU3NDYwYTNmYzhhZjF
mOWI4ZTFmNTFkNjNkN2FlNmM3ZjAzZjg0MmJjYjQ0OWNkZmU4Mjc4YTY5O
Dc5NmE3ODAwMGJkZjJmNDIxZWU2YzU3Y2Q1MjIxOGYwNTE3MTRlMTE1Yj
RiYTI1NjhhMzY0MmRjNDVjYWY5Y2I4MDIzNmYzNDNkNGFiOTJhODM1OWU2
YTQ0YzRmZTU2MmUzNjRhNGYyYzkwZjhkY2Y3ODIzM2I5N2NkOTA0OGZkZ
DM1NGY0NzJmMmU2YTk4Y2ZiNmU1MTBkMGI3MTVkIiwidXNlclRleHQiOiJXZ
Wxjb21lIFJvYiJ9.2xGoGnrdFjMf6rn5GEkOAlHamFPceQC6jiS4M6siPb0
Wed, 30 Aug 2017 11:34:27 GMT; worker 13037 received message:
{"type":"save","params":
{"path":"/api/store/store1/stocklist","method":"GET","store":"store1","stock":"stock
list

Inspect the JWT using jwt.io

Inspect the JWT using jwt.io
This is why the QEWD Worker
Is looking for a module named
stock-list

Let's create that module
• On your Primary server, create a new text
file:
– ~/qewd/node_modules/stock-list.js

• On your Primary server, create a new text
file:
– ~/qewd/node_modules/stock-list.js
module.exports = {
handlers: {
save: function(messageObj, session, send, finished) {
messageObj.handledByWorker = process.pid + ' at ' + Date.now();
finished(messageObj);
}
}
};

module.exports = {
handlers: {
}
}
};
For the purpose of this example/demo, we're
just going to send the incoming message
back to the Master process

module.exports = {
handlers: {
}
}
};
But so that we can be sure that a Worker really
handled it, we'll add this to the message

Try It
• Restart QEWD on the Primary Server
• Login again and copy the JWT to the
Authorization Header
• Then send:

Try It
You should see a response similar to this

Try It
You can see it's the message we sent to the Worker for processing

Try It
Here's the additional property added by our
Worker module's handler function

By running in a Worker
• You have access to the integrated QEWD
database
• You have access to the Session data
contained within the JWT

Let's enhance that module
module.exports = {
handlers: {
var db = this.db.use('stockList');
var ix = db.increment();
db.$(ix).setDocument(messageObj);
}
}
};
For example, we could save the message object
to the database

Let's enhance that module
module.exports = {
handlers: {
session.customHandledAt = Date.now();
}
}
};
And we could add a new data item to the Session / JWT

Try It
• Restart QEWD
• Login and copy the JWT to the
Authorization Header as before
• Send:

Now Check the Database using
qewd-monitor
Click the
Document Store
Tab

Now Check the Database using
qewd-monitor
Here's the saved
Document we
created, containing
the message we
sent to the Worker

Reminder of how that happened
module.exports = {
handlers: {
session.customHandledAt = Date.now();
}
}
};

Now Inspect the JWT
Copy this token and paste
it into the jwt.io inspector

Now Inspect the JWT
Here's the field we
added to the Session
and therefore to the JWT

• So far you've learned how to:
– re-package / re-format the response from a
MicroService
– Process the response from a MicroService, including:
• saving some or all of it to the QEWD database
• Modifying the JWT before returning the response to the
REST client
• You should be able to adapt the examples to
make the behaviour conditional on the response
content

• What if you wanted to trigger a new request to
another MicroService, eg:
– Make the /api/login request to the Primary Server:
• Invoke the call to the authentication MicroService to log us in
(using the username and password credentials), as we've
done already
• But then, if successful, make a call to a demographics
MicroService to get some basic information about the
logged-in user
• Add those demographic details to the response that is
returned to the REST client

What we'll need to use:
• The args object, passed as an argument
to your onResponse() handler function
contains two properties are functions:
– args.send
• If you want to send a request to another
MicroService, you use this function

• We've already seen how to use this to return our
customised response back to the REST client
– args.send

– args.send
• Now we'll use this function, which allows us to
send a new request to a MicroService

We'll use these two routes
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
This is the startup
file for the Primary
server

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
The demographics
route was described
in detail at the start of
this Part of the course

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
For this example,
both routes are
handled by the same
destination, but they
could be at different
destinations

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
The demographics
route expects a
variable value – the
patientId
Let's first change
the login MicroService
so it returns an id
that we can use for
the demographics
route

Modify the Login MicroService
• On your Login MicroService machine, find
the handler module:
– We'll edit the login() function

session.userId = 123456;
}
else {
}
}
Add this line
For simplicity, in this
Example, we're just
hard-coding an Id
In the real-world we'd
probably do some kind
of database lookup

• What this modification will do is add the
userId to the JWT that is returned to the
Primary server
• Stop and restart the Login MicroService
and try logging in again

Modified Login MicroService Response
So the Login MicroService returns 2 properties: ok and token
Let's copy and paste the token and inspect it using jwt.io

Modified Login MicroService Response
So here's the new userId field that we added

Custom Login Response Handler
• We now need to go back to the startup file
on your Primary Server, and add an
onResponse() handler function to the
Login route definition

Primary Server Startup File
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
application: 'login-micro-service',
}
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
method: 'GET',
}
]
}
};
We'll zoom in
here on the next
slides..

Modified Login Response Handler
routes: [
{
path: '/api/login',
method: 'POST',
destination: 'login_service',
var userId = this.jwt.handlers.getProperty('userId', args.responseObj.message.token);
var message = {
path: '/api/patient/' + userId + '/demographics',
method: 'GET',
headers: {
authorization: 'Bearer ' + args.responseObj.message.token
}
};
args.send(message, function(responseObj) {
responseObj.message.ok = args.responseObj.message.ok;
});
return true;
}
}
},

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
We'll only make a call to the demographics service
if the login was successful

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
Use this.jwt.handlers.getProperty() to extract a
public claim from the JWT – in this case the userId
This doesn't require the secret, so is lightweight
enough to perform in the master process

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
The first argument specifies the
Property or Claim name we want

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
The 2nd
argument is a JWT. We'll use
the JWT returned in the Login
MicroService response

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
Next, we construct a minimal message object to
send a demographics MicroService request

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
The path will match that of the demographics route
We add into the path the userId extracted from the
Login JWT

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
The HTTP method we want to use is GET

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
Finally, we must add the authorization header.
The format must be the same as if we'd
submitted the request from a REST client
We'll use the JWT returned by the Login MicroService

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
If the MicroService we want to use had a POST
method, we'd need to specify a body object in
the message.
If the URL needed additional name/value pairs,
we'd add a query object to the method

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
The message object should be sufficient for
the demographics MicroService, so now
we send it using the args.send() function

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
We want to combine the response from the
Login MicroService with what comes back from
the Demographics MicroService, so we'll do that
in the arg,send callback function

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
We'll get the ok property from the Login response
In other situations you might have many more
properties to merge into the final response

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
And now we're ready to return the composite
response back to the REST client.
We use args.handleResponse() for this, as before

routes: [
{
path: '/api/login',
method: 'POST',
var message = {
method: 'GET',
headers: {
}
};
});
return true;
}
}
},
One last very important step – we must tell
QEWD that we're handling the response

Try It
• Restart QEWD on the Primary and Login
MicroService servers
• Send:
– GET /api/login
• With the appropriate body payload containing the
username and password

Try It
Success!

Try It
These properties came from the Demographics service

Try It
And this came from the Login service

Recap so far
• You've now learned how to:
– Use templated routes with variable path
components
– Add custom response handling
• And optionally perform some or all of that handling
in a QEWD worker process, allowing:
– use of the integrated QEWD document database
– The JWT contents to be manipulated
• And optionally send one or more further requests
to MicroServices and construct a composite
response

All on the Primary Server
• Everything we've done so far in this Part of
the Course has been on the Primary
Server

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
& demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Login Request

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
& demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Login Response

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
& demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Demographics
Request

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
& demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
WebSocket
Connections
Demographics
Response

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
& demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Composite
Response

What about the MicroService Servers?
• Is it possible for a MicroService to make
requests to other MicroServices?
– In other words…

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Login Request

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Demographics
Request

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Demographics
Response

ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
User authentication
Demographics
ewd-qoper8
queue
Express
Node.js
socket.io
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
Cache
GT.M,
YottaDB
Redis
Node.js
Worker
Process
HTTPS
WebSocket
Connections
Login Response

Lets build out the 3 servers
• Primary Server
– Will handle the /api/login request sent from the REST
client
• Login Server
– Will handle the /api/login request sent from the
Primary Server
• Demographics Server
– Will handle the /api/patient/:patientId/demographics
request sent from the Login Server

Primary Server
• Startup File
– ~/qewd/primary.js

Primary Server (1)
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
};

Primary Server (2)
var routes = [
{
path: '/api',
module: 'localServices'
}
];

Primary Server (1) - Notes
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
};
The Primary Server only
knows the route to the
Login Server

var config = {
serverName: 'Primary QEWD Server',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.121:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
};
Adjust to match your
Login Server location

var routes = [
{
path: '/api',
module: 'localServices'
}
];
Our example is only going
to respond to incoming
requests for /api/login which
it will forward to the Login
MicroService server.
We won't be handling any
other routes locally on this
server. Nevertheless,
the Primary Server needs
to know to recognise any
paths starting /api, so we
need to specify it as a
notional route
We'll specify a non-existent
local handler module named
localServices that won't
actually get used

Login Server
• Startup file:
– ~/qewd/loginserver.js
• Worker Module for handling the /api/login
login requests
• ~/qewd/node_modules/login-micro-service.js

Login Server: Startup File
var config = {
serverName: 'QEWD Login MicroService',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
demographics: {
host: 'http://192.168.1.114:8080',
application: 'demographics'
}
},
routes: [
{
method: 'GET',
destination: 'demographics'
}
]
}
};
qewd.start(config);

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
demographics: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
method: 'GET',
}
]
}
};
qewd.start(config);
The Login Server needs
to know the route to
the Demographics
MicroService

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
demographics: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
method: 'GET',
}
]
}
};
qewd.start(config);
Adjust to match your
Demographics
Server location

Login Server: Worker Module (1)
var routes;
session.userId = 123456;
}
else {
}
}
This file is too
long to fit on
one slide
This is part 1
See next slide
for the rest of
the file

Login Server: Worker Module (2)
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
},
workerResponseHandlers: {
restRequest: function(message, send) {
if (message.path === '/api/login') {
var ok = message.ok;
var userId = this.jwt.handlers.getProperty('userId', message.token);
var message = {
method: 'GET',
headers: {
authorization: 'Bearer ' + message.token
}
};
this.microServiceRouter.call(this, message, function(responseObj) {
responseObj.message.ok = ok;
send(responseObj);
});
return true;
}
}
}
};

The key new piece
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
},
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}
};

The key new piece
Any QEWD Worker Module can have a workerResponseHandlers object
defined. It is used to define handler functions that are invoked in the Master
Process for any specified message type, once that message's worker-side
handler has finished
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
The workerResponseHandlers handler function for a message type is
invoked after the main handler function has completed, and before
the response is returned to the client. We can use this to intercept the
Normal MicroServices flow.
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
QEWD MicroServices always use a pre-determined message type of
restRequest. So we're defining a workerResponseHander function that
will intercept all microService responses.
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
So the first thing we must do is filter out the one(s) we're interested in. In fact
In the example there will only be one MicroService request type hitting this
Code – for /api/login - but you'll often need to know how to do this
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
For MicroService messages (ie of type restRequest), QEWD adds the path
(actually the path template) to the message argument.
So we can filter on this as shown
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
We need to know the user Id for the logged in user. So, just as we did
earlier, we'll extract it from the JWT. It's in message.token
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

The key new piece
Now we can call out to the demographics MicroService. We create a
message object containing, at minimum, the path, method and headers
This is just the same as we did before when we called the MicroService
from the Primary Server
var message = {
method: 'GET',
headers: {
}
};
send(responseObj);
});
return true;
}
}
}

getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details

getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details

Similar to getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details (20)

More from Rob Tweed

More from Rob Tweed (14)

Recently uploaded

Recently uploaded (20)

getDemographics = function(message) {// message.path will contain the actual path// message.template will contain the template path// message.parameters will contain the parameter values// ...}Handle the request based on the message details