EWD 3 Training Course Part 44: Creating MicroServices with QEWD.js

Copyright © 2016 M/Gateway Developments Ltd
EWD 3 Training Course
Part 44
Creating MicroServices with QEWD.js
Rob Tweed
Director, M/Gateway Developments Ltd
Twitter: @rtweed

Using JSON Web Tokens with
QEWD REST Services
• 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

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

• MicroService routes are defined in the
QEWD Startup file
• On startup, WebSocket connections are
established between the primary
orchestrating QEWD system(s) and the
MicroService QEWD Systems
• MicroService Routing is handled by the
QEWD Master Process

• Incoming requests to the orchestrating
QEWD Server are over REST/HTTP(S)
• If the requests are destined for a
MicroService, they are converted to
QEWD WebSocket messages
• Incoming requests on MicroService
QEWD systems are handled as QEWD
WebSocket requests

• QEWD MicroServices rely on JWTs for
authentication and Session/State
management
• All participating QEWD systems must be
configured with the same JWT secret

Let's Get Started!

Simple Example
• Two QEWD systems
– One will be the primary orchestrating system
that will be the endpoint for incoming REST
requests
• We'll refer to this as the Primary QEWD Server
– One will be used as a user authentication
service
• We'll refer to this as the Login MicroService server

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
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

Configuring the Primary Server

Startup file from Part 43
var config = {
managementPassword: 'keepThisSecret!',
serverName: 'QEWD REST Server',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
secret: 'someSecret123'
}
};
var routes = [
{path: '/api', module: 'myRestService'}
];
var qewd = require('qewd').master;
qewd.start(config, routes);

Add the MicroService Definition
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {},
routes: []
}
};
var routes = [
];

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {},
routes: []
}
};
var routes = [
];
Two parts to the MicroService Configuration:
-destinations: defines the endpoints
-routes – assigns URL paths to destinations

jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
application: 'login-micro-service'
}
},
routes: []
}
};

jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: []
}
};
You give each destination a name
(your choice what it's called)

jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: []
}
};
A destination defines:
-a QEWD host endpoint URL

jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: []
}
};
A destination defines:
-The Application name assigned for this destination
(ie the application on the remote machine that
will handle incoming requests for this service
destination)

jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
destination: 'login_service'
}
]
}
};

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
Each Route is defined by an array element

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
Each Route is defined by:
- A URL path (which can be templated)

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
-optionally, an HTTP method
If not specified, the route will apply to
all HTTP methods for the path

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
-the MicroService destination to which
the request will be routed

MicroService Routes Override Local Routes
• Look in the Startup file and you'll see it
also contains a route for locally processing
all incoming REST requests starting /api:
var routes = [
];

MicroService Routes Override Local Routes
• Our MicroService route for /api/login will
take preference over this
var routes = [
];

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
You can define as many Routes and
Destinations as you like

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
},
info_service: {
host: 'http://192.168.1.115:8080',
application: 'info-micro-service'
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
Destinations can be at different
physical endpoints

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
},
info_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
The same physical endpoint can appear
in more than one Destination

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
},
info_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
The same physical endpoint can appear
in more than one Destination
In which case the application will be
different

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
},
info_service: {
host: 'http://192.168.1.115:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
path: '/api/info',
method: 'GET',
destination: 'info_service'
}
]
}
Each Route can use different Destinations

u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
},
{
path: '/api/userinfo',
method: 'GET',
}
]
}
Each Route can use different Destinations
or the same ones

Our Example MicroService Definition
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
};
In our example we'll just define a single
Destination and Route
POST requests for /api/login will be routed
to the MicroService QEWD system
at 192.168.1.114:8080, where they will be
handled by the login-micro-service
application

Our Example MicroService Definition
var config = {
serverName: 'New QEWD Server',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
},
u_services: {
destinations: {
login_service: {
host: 'http://192.168.1.114:8080',
}
},
routes: [
{
path: '/api/login',
method: 'POST',
}
]
}
};
var routes = [
{
path: '/api',
module: 'myRestService',
errors: {
notfound: {
text: 'Resource Not Recognised',
statusCode: 404
}
}
}
];
var q = qewd.start(config, routes);
Save as ~/qewd/ms-startup.js
Change the IP address/
domain name of the
login_service host
property to match the server
you'll be using

Next we'll configure the MicroService System

Next we'll configure the MicroService System
• Remember – we'll now be working on your
second QEWD server
• As our starting point, we'll use that original
startup file from Part 43 again…

MicroService Startup file
var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
}
};
var routes = [
];
Important: we'll use the same
JWT Secret

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
}
};
var routes = [
];
We don't need this, however,
even though this QEWD
system will be handling
forwarded requests for
/api/login

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
}
};
qewd.start(config);
That's because the primary
QEWD system will re-format
the /api/login REST requests to
a WebSocket message

var config = {
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
}
};
qewd.start(config);
That's because the primary
QEWD system will re-format
the /api/login REST requests to
a WebSocket message
These messages will be handled
by the login_micro-service
application on this QEWD system

var config = {
serverName: 'QEWD Login MicroService',
port: 8080,
poolSize: 2,
database: {
type: 'gtm'
},
jwt: {
}
};
qewd.start(config);
Save this file as:
~/qewd/loginservice.js

Start Up the Two QEWD Systems
• It doesn't matter which you start up first
• Let's start the main one first and see what
happens

On the primary QEWD machine:
cd ~/qewd
node ms-startup

Look at the QEWD Node
Console Log
rtweed@ubuntu:~/qewd$ node microservices
Setting up micro-service connections
Adding MicroService Client connection: url = http://192.168.1.114:8080; application = login-micro-service
starting microService connection to http://192.168.1.114:8080
webServerRootPath = /home/rtweed/qewd/www/
route /api will be handled by qx.router

Look at the QEWD Node
Console Log
QEWD hasn't fully started yet
It's waiting for a response from the MicroService
machine on 192.168.1.114:8080
Which, of course, hasn't been started yet

On the QEWD Login MicroService machine:
cd ~/qewd
node loginservice

Look at the QEWD Node Console
Log on the MicroService machine
rtweed@ubuntu:~/qewd$ node loginService
Worker Bootstrap Module file written to node_modules/ewd-qoper8-worker.js
========================================================
ewd-qoper8 is up and running. Max worker pool size: 2
========================================================
QEWD.js is listening on port 8080
========================================================
** sockets: incoming message received: {"type":"ewd-register","application":"login-micro-service","jwt":true,"socketId":"L7OwOn
Siqhr-nAmdAAAA","ipAddress":"::ffff:192.168.1.119"}
no available workers
sent qoper8-start message to 30140
process.argv[2] = qewd.worker
workerModule: qewd; worker
Session Garbage Collector has started in worker 30140
Tue, 22 Aug 2017 09:47:46 GMT; master process received response from worker 30140: {"type":"workerProcessStarted","ok":30140}
new worker 30140 started and ready so process queue again
Tue, 22 Aug 2017 09:47:46 GMT; worker 30140 received message: {"type":"ewd-register","application":"login-micro-service","jwt":
true,"socketId":"L7OwOnSiqhr-nAmdAAAA","ipAddress":"::ffff:192.168.1.119"}
Tue, 22 Aug 2017 09:47:46 GMT; master process received response from worker 30140: {"type":"ewd-register","finished":true,
"message":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTU1NjYsImlhdCI6MTUwMzM5NTI2Niwia
XNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0IjozMDAsInFld2QiOiJmZTc0
U5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.DsDntCU3x2w21K3vmK3iaJd1kOhIj_Rl9h1
0469qXu4"}}
*** handleMessage response {"type":"ewd-register","finished":true,"message":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.e
hOTE0OGQ4Nzg1N2ZiZWM5Nzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdjZDUyMjE4ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM
0NWNhZjljYjgwMjM2ZjM0M2Q0OWIwMmE4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.D
sDntCU3x2w21K3vmK3iaJd1kOhIj_Rl9h10469qXu4"}}
Response time: 313ms

Look at the QEWD Node Console
Log on the MicroService machine
rtweed@ubuntu:~/qewd$ node loginService
========================================================
========================================================
========================================================
** sockets: incoming message received: {"type":"ewd-register","application":"login-micro-service","jwt":true,"socketId":"L7OwOn
Siqhr-nAmdAAAA","ipAddress":"::ffff:192.168.1.119"}
no available workers
sent qoper8-start message to 30140
process.argv[2] = qewd.worker
workerModule: qewd; worker
Session Garbage Collector has started in worker 30140
Tue, 22 Aug 2017 09:47:46 GMT; master process received response from worker 30140: {"type":"workerProcessStarted","ok":30140}
new worker 30140 started and ready so process queue again
Tue, 22 Aug 2017 09:47:46 GMT; worker 30140 received message: {"type":"ewd-register","application":"login-micro-service","jwt":
true,"socketId":"L7OwOnSiqhr-nAmdAAAA","ipAddress":"::ffff:192.168.1.119"}
Tue, 22 Aug 2017 09:47:46 GMT; master process received response from worker 30140: {"type":"ewd-register","finished":true,
"message":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTU1NjYsImlhdCI6MTUwMzM5NTI2Niwia
XNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0IjozMDAsInFld2QiOiJmZTc0
U5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.DsDntCU3x2w21K3vmK3iaJd1kOhIj_Rl9h1
0469qXu4"}}
*** handleMessage response {"type":"ewd-register","finished":true,"message":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.e
hOTE0OGQ4Nzg1N2ZiZWM5Nzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdjZDUyMjE4ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM
0NWNhZjljYjgwMjM2ZjM0M2Q0OWIwMmE4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.D
sDntCU3x2w21K3vmK3iaJd1kOhIj_Rl9h10469qXu4"}}
QEWD has fully started

Notice This Activity…
Tue, 22 Aug 2017 09:47:46 GMT; worker 30140 received message: {"type":"ewd-register",
"application":"login-micro-service","jwt":true,"socketId":"L7OwOnSiqhr-nAmdAAAA",
"ipAddress":"::ffff:192.168.1.119"}
Tue, 22 Aug 2017 09:47:46 GMT; master process received response from worker 30140:
{"type":"ewd-register","finished":true,"message":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUz
I1NiJ9.eyJleHAiOjE1MDMzOTU1NjYsImlhdCI6MTUwMzM5NTI2NiwiaXNzIjoicWV3ZC5qd3Q
iLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0IjozMDAsInFld2Q
iOiJmZTc0NjBhM2ZjOGFmMWY5YjhlMWY1MWQ2M2FmYjQ3YTU5M2JkZDczYjNhOTE0OG
Q4Nzg1N2ZiZWM5Nzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdjZDUyMjE4ZjA1MTcxNGUxMT
ViNGJhMjU2OGEzNjQyZGM0NWNhZjljYjgwMjM2ZjM0M2Q0OWIwMmE4MzU5ZTZhNDRjNG
ZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.DsDntCU3x2w21K3vmK3iaJ
d1kOhIj_Rl9h10469qXu4"}}
*** handleMessage response {"type":"ewd-register","finished":true,"message":{"token":"eyJ0e
XAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTU1NjYsImlhdCI6MTUwMzM5NTI
2NiwiaXNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ
0aW1lb3V0IjozMDAsInFld2QiOiJmZTc0NjBhM2ZjOGFmMWY5YjhlMWY1MWQ2M2FmYjQ3Y
TU5M2JkZDczYjNhOTE0OGQ4Nzg1N2ZiZWM5Nzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdj
ZDUyMjE4ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM0NWNhZjljYjgwMjM2ZjM0M2Q0O
WIwMmE4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3I
n0.DsDntCU3x2w21K3vmK3iaJd1kOhIj_Rl9h10469qXu4"}}

What Happened?
• When the QEWD MicroService machine
started, the primary machine was able to
establish a WebSocket connection to it
• It then registered the login-micro-service
application on the QEWD MicroService
machine, using a JWT

Now look at the Primary QEWD
Machine's Console Log
login-micro-service registered
http://192.168.1.114:8080 micro-service ready
========================================================
========================================================
========================================================
Connection was established to the Login MicroService
QEWD system, and the login-micro-service application
was registered

Now look at the Primary QEWD
Machine's Console Log
login-micro-service registered
http://192.168.1.114:8080 micro-service ready
========================================================
========================================================
========================================================
So QEWD has now fully started
Both QEWD systems are ready!

Startup Sequence Doesn't Matter
• You can try stopping both QEWD systems (just
CTRL & C each of them)
• Restart the Login MicroService QEWD system
first
– It will start up fully and wait for incoming requests
• Then start the primary QEWD system
– It will connect to the Login MicroService QEWD
machine immediately
– You'll see the Login machine receive the registration
request
– The primary machine will then start QEWD

You can shut down and restart either server
• You can try stopping and restarting either
QEWD system
• After a brief pause, you'll see the two servers re-
communicating and re-registering

Ready to test the /api/login request
• Use a REST Client
• POST the /api/login request to the primary
QEWD server

Try POST /api/login

Try POST /api/login
Not surprising – we haven't yet written a handler
For the login-micro-service application to handle
This request on the MicroService machine…..but...

Look at the Console Log for
both machines
• You'll see that they both burst into life

Primary Machine
sent: {"application":"login-micro-service","type":"restRequest","path":"/api/login",
"pathTemplate":"/api/login","method":"POST","headers":{"host":"192.168.1.119:8080",
"content-length":"41","content-type":"application/json"},"params":{"type":"login"},"query":{},
"body":{"username":"rob","password":"secret"},"ip":"::ffff:192.168.1.74","ips":[],"token":"eyJ
0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTk1NzMsImlhdCI6MTUwMz
M5OTI3MywiaXNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcn
ZpY2UiLCJ0aW1lb3V0IjozMDAsInFld2QiOiJmZTc0NjBhM2ZjOGFmMWY5YjhlMWY1MW
Q2MzhlZWM1OTZiMmJlYzU1YTI5MTRlODljNThmNTE4YTgwNzk2YTc4MmYwYmRmMm
Y0MjFlZTZjNTdjZDUyMjE4ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM0NWNhZjljYj
gwMjM2ZjM0M2Q0OWIwMmE4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZ
jc4MzEyODhlZGJkOTE3In0.Re4a6cEmIzQ9PFhwwYsoQ-UtMBKHkTPSpAk55FCDyV8",
"args":{},"jwt":true}
received: {"type":"restRequest","finished":true,"message":{"error":"Unable to load handler
module for: login-micro-service","reason":{"code":"MODULE_NOT_FOUND"}},
"responseTime":"14ms"}

Login MicroService Machine
Tue, 22 Aug 2017 10:54:33 GMT; worker 30188 received message: {"application":
"login-micro-service","type":"restRequest","path":"/api/login","pathTemplate":"/api/login",
"method":"POST","headers":{"host":"192.168.1.119:8080","content-length":"41",
"content-type":"application/json"},"params":{"type":"login"},"query":{},"body":{"username":"rob"
,"password":"secret"},"ip":"::ffff:192.168.1.74","ips":[],"token":"eyJ0eXAiOiJKV1QiLCJhbGci
OiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTk1NzMsImlhdCI6MTUwMzM5OTI3MywiaXNzIjoicWV
3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0Ijoz
MDAsInFld2QiOiJmZTc0NjBhM2ZjOGFmMWY5YjhlMWY1MWQ2MzhlZWM1OTZiMmJlYz
U1YTI5MTRlODljNThmNTE4YTgwNzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdjZDUyMjE4
ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM0NWNhZjljYjgwMjM2ZjM0M2Q0OWIwMm
E4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.R
e4a6cEmIzQ9PFhwwYsoQ-UtMBKHkTPSpAk55FCDyV8","args":{},"jwt":true}
Unable to load handler module for: login-micro-service: Error: Cannot find module
'login-micro-service'
Tue, 22 Aug 2017 10:54:33 GMT; master process received response from worker 30188:
{"type":"restRequest","finished":true,"message":{"error":"Unable to load handler module for:
login-micro-service","reason":{"code":"MODULE_NOT_FOUND"}}}
*** handleMessage response {"type":"restRequest","finished":true,"message":{
"error":"Unable to load handler module for: login-micro-service","reason":{
"code":"MODULE_NOT_FOUND"}}}

Tue, 22 Aug 2017 10:54:33 GMT; worker 30188 received message: {"application":
"login-micro-service","type":"restRequest","path":"/api/login","pathTemplate":"/api/login",
"method":"POST","headers":{"host":"192.168.1.119:8080","content-length":"41",
"content-type":"application/json"},"params":{"type":"login"},"query":{},"body":{"username":"rob"
,"password":"secret"},"ip":"::ffff:192.168.1.74","ips":[],"token":"eyJ0eXAiOiJKV1QiLCJhbGci
OiJIUzI1NiJ9.eyJleHAiOjE1MDMzOTk1NzMsImlhdCI6MTUwMzM5OTI3MywiaXNzIjoicWV
3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6ImxvZ2luLW1pY3JvLXNlcnZpY2UiLCJ0aW1lb3V0Ijoz
MDAsInFld2QiOiJmZTc0NjBhM2ZjOGFmMWY5YjhlMWY1MWQ2MzhlZWM1OTZiMmJlYz
U1YTI5MTRlODljNThmNTE4YTgwNzk2YTc4MmYwYmRmMmY0MjFlZTZjNTdjZDUyMjE4
ZjA1MTcxNGUxMTViNGJhMjU2OGEzNjQyZGM0NWNhZjljYjgwMjM2ZjM0M2Q0OWIwMm
E4MzU5ZTZhNDRjNGZlNTYyZTM2NGE0ZjJjOTBmOGRjZjc4MzEyODhlZGJkOTE3In0.R
e4a6cEmIzQ9PFhwwYsoQ-UtMBKHkTPSpAk55FCDyV8","args":{},"jwt":true}

Incoming WebSocket Message
{
"application": "login-micro-service",
"type": "restRequest",
"path": "/api/login",
"pathTemplate": "/api/login",
"method": "POST",
"headers": {
"host": "192.168.1.119:8080",
"content-length": "41",
"content-type": "application/json"
},
"params": {
"type": "login"
},
"query": {},
"body": {
"username": "rob",
"password": "secret"
},
"ip": "::ffff:192.168.1.74",
"ips": [],
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.ey...",
"args": {},
"jwt": true
}

Unable to load handler module for: login-micro-service: Error: Cannot find module
'login-micro-service'

Tue, 22 Aug 2017 10:54:33 GMT;
master process received response from worker 30188:
{"type":"restRequest","finished":true,"message":{"error":"Unable to load handler module for:
login-micro-service","reason":{"code":"MODULE_NOT_FOUND"}}}
*** handleMessage response {"type":"restRequest","finished":true,"message":{
"error":"Unable to load handler module for: login-micro-service","reason":{
"code":"MODULE_NOT_FOUND"}}}

So let's add a Login Handler
• On the Login MicroService machine
– 192.168.1.114 in our example
– Create a new text file:
• ~/qewd/node_modules/login-micro-service.js

Login Handler Module
• We could write a standard QEWD
WebSocket message handler function to
deal with the re-packaged incoming
message
– Here's what it looked like

• We could write a standard QEWD
WebSocket message handler function to
deal with the re-packaged incoming
message
• But QEWD provides a set of shortcuts to
make it even simpler
– And to allow you to define multiple handler
functions based on the original URL paths,
using templated paths if you wish

var router = require('qewd-router');
var routes;
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
router.addMicroServiceHandler(routes, module.exports);
}
};

var routes;
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
First we need to define
an init() function in which we'll
define our URL routes

var routes;
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
Inside this function, we define a
routes object for all the routes
we want to handle.
We only have one:
POST /api/login

var routes;
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
Inside this function, we define a
routes object for all the routes
we want to handle.
We only have one:
POST /api/login
And it will invoke a handler function
named login() (which we haven't
yet written)

var routes;
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
}; Then we can run this QEWD
API which constructs the
handler function stubs for us
within the module

var routes;
function login(args, finished) {
// this will handle the login message
}
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
Next we define the login function

var routes;
}
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
Next we define the login() function
It's the same function interface
that you use for standard
REST route handling
The addMicroServiceHandler()
API normalises the interface
for you

var routes;
}
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
REST route handling
args is an object containing:
-req: incoming request object
-session: the JWT payload

var routes;
}
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
REST route handling
-finished is the function for
returning the response and
releasing the worker process

Incoming WebSocket Message
{
"application": "login-micro-service",
"type": "restRequest",
"path": "/api/login",
"pathTemplate": "/api/login",
"method": "POST",
"headers": {
"host": "192.168.1.119:8080",
"content-length": "41",
"content-type": "application/json"
},
"params": {
"type": "login"
},
"query": {},
"body": {
"username": "rob",
"password": "secret"
},
"ip": "::ffff:192.168.1.74",
"ips": [],
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.ey...",
"args": {},
"jwt": true
}
We POSTed
{"username":"rob","password":"secret"}
So the user login credentials
will be in the message body object

function login( args, finished) {
var username = args.req.body.username;
var password = args.req.body.password;
if (username === 'rob' && password === 'secret') {
// valid login credentials
}
else {
// invalid login – return an error
}
}
We'll just hard-code the
valid credentials for simplicity
in this example

var session = args.session;
session.userText = 'Welcome Rob';
session.username = username;
// return success response
}
else {
}
}
Update the session object
With our own data

session.authenticated = true;
session.timeout = 1200;
}
else {
}
}
These are reserved session
properties
authenticated helps determine
that the user was properly
logged in
timeout determines the JWT
timeout each time QEWD
updates it

session.makeSecret('username');
session.makeSecret('authenticated');
}
else {
}
}
Make these two session properties
secret. QEWD will encrypt them
within the JWT so they aren't
accesible or usable by the client.
They will be available, however,
for your back-end handler
functions

finished({ok: true});
}
else {
}
}
Return a success response object
and release the worker process

finished({ok: true});
}
else {
return finished({error: 'Invalid login'});
}
}
Return an error response object
and release the worker process

Save the Login Handler Module
var routes;
return finished({ok: true});
}
else {
return finished({error: 'Invalid login'});
}
}
module.exports = {
init: function() {
routes = {
'/api/login': {
POST: login
}
};
}
};
~/qewd/node_modules/login-micro-service.js

Restart the QEWD on the Login
machine and re-try POST /api/login
Now it works!

Restart the QEWD on the Login
machine and re-try POST /api/login
Notice that although we just asked to return {ok: true},
it's returned an updated JWT also

Let's decode that JWT

Here are the non-secret properties we set in the
login() function

The secret ones are encrypted into this claim

Try an invalid POST /api/login request
Notice that although we just asked to return {ok: true},
it's returned an updated JWT also

There's the error message
We created in the login()
function

Note that when an error is
reported, the JWT is not
updated

We now have a working MicroService!

We now have a working MicroService
• Let's now add a local API to the primary
QEWD system
– that can't be run until the user has logged in
via the Login MicroService

Already Have a Local Route Defined
var routes = [
{
path: '/api',
errors: {
notfound: {
statusCode: 404
}
}
}
];

var routes = [
{
path: '/api',
errors: {
notfound: {
statusCode: 404
}
}
}
];
All /api requests other than /api/login will
be handled locally by the myRestService
Worker process Handler module

var routes = [
{
path: '/api',
module: 'myLocalServices',
errors: {
notfound: {
statusCode: 404
}
}
}
];
Let's change the name of the
handler module to
myLocalServices, to avoid
confusion

Create a new Handler Module
On the primary QEWD machine:
~/qewd/node_modules/myLocalServices.js
var routes;
module.exports = {
restModule: true,
init: function() {
},
beforeHandler: function(req, finished) {
}
};

var routes;
module.exports = {
restModule: true,
init: function() {
routes = [
{
url: '/api/info',
method: 'GET',
handler: info
}
]
routes = router.initialise(routes, module.exports);
},
}
};
Define a route to be handled
GET /api/info will be handled by
a function named info()

var routes;
module.exports = {
restModule: true,
init: function() {
routes = [
{
url: '/api/info',
method: 'GET',
handler: info
}
]
},
}
};
Tell QEWD to set up the
Handler function stubs
Automatically within the
module

var routes;
module.exports = {
restModule: true,
init: function() {
routes = [
{
url: '/api/info',
method: 'GET',
handler: info
}
]
},
}
};
The beforeHandler() function
will be invoked for every incoming
/api request
We'll use this to confirm that the
user has logged in before allowing
the incoming request to be handled

// invoked for every incoming request,
// before the route-specific handler
}
If the beforeHandler() function returns false,
then the route-specific handler won't get
called.
Any other return value (including
undefined) will allow the route-specific
handler to run

return this.jwt.handlers.validateRestRequest.call(this, req, finished);
}
Add this code inside the
beforeHandler() function

}
Use this built-in API to extract, validate and
decrypt the incoming JWT in the request's
Authorization header
All incoming requests will now need to have a
Valid JWT, otherwise they'll be rejected

}
Returns an error, releases the worker process
and ceases any further handling of the request if:
-No Authorization Header was found
-No JWT was found in the Authorization Header
-The JWT signature wasn't valid
-The JWT had expired

}
Returns an error, releases the worker process
and ceases any further handling of the request if:
-No Authorization Header was found
-No JWT was found in the Authorization Header
-The JWT signature wasn't valid
-The JWT had expired
Otherwise, adds the extracted, decrypted payload
to the request as a Session object, and allows the
route-specific handler to be invoked

var routes;
function info(args, finished) {
}
module.exports = {
restModule: true,
init: function() {
routes = [
{
url: '/api/info',
method: 'GET',
handler: info
}
]
},
//... etc
}
};
Now we'll add the info() function

args.session.ranInfoAt = Date.now();
var username = args.session.username;
console.log('*** info args: ' + JSON.stringify(args, null, 2));
var jwt = this.jwt.handlers.setJWT.call(this, args.session);
finished({
info: {
server: 'ubuntu119',
loggedInAs: username,
arch: process.arch,
platform: process.platform,
versions: process.versions,
memory: process.memoryUsage()
},
token: jwt
});
}
Add this code inside the info()
function

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
By the time the info() handler function
runs, the Session object has
been made available as args.session.
We'll add a new property to the Session:
-ranInfoAt which is the time when
the function was run

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
username was specified as a
private JWT/Session value by
the Login MicroService. However,
our handler function can access
it because this server has the
same JWT Secret

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
You'll be able to see the decrypted,
unpacked JWT payload displayed
in the Node.js Console log

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
We'll create a new JWT from
the updated Session contents
This will also update the JWT's
expiry time

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
We'll return some items of
Information about the server
We'll also display the username
(which was a secret claim in
The JWT)

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
And finally we'll also return
the updated JWT
The Worker process will
then be released

finished({
info: {
arch: process.arch,
},
token: jwt
});
}
Save as ~/qewd/node_modules/myLocalServices.js

Restart the Primary QEWD System and Try
the GET /api/info request

Add an invalid Authorization Header

Add an invalid JWT

Now Login using the Login MicroService
Note: Make sure you remove the Authorization Header!

Successful Login

Paste the JWT into the Authorization
Header and try GET /api/info request again

Success!

Check the Node.js Console Logs
• When you run the POST /api/login
request, you'll see activity on both servers
– Request passed to Login MicroService and
response returned to primary QEWD server

Check the Node.js Console Logs
• When you run the GET /api/info request,
there's only activity on the primary QEWD
Server as it's handled locally
– But it's only allowing the request to be
handled locally if the JWT from the Login
MicroService is present

Adding More Local Routes
• You can add as many additional local
routes as you want to the primary QEWD
server's Worker Process handler module
• The beforeHandler() function will be
automatically invoked before any of them
are handled, so all will be authenticated
• Each one should follow the pattern we
used for the /api/info route definition and
info() function

QEWD MicroServices
• You should now have all the information
you need to build a set of MicroServices
using QEWD systems

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

EWD 3 Training Course Part 44: Creating MicroServices with QEWD.js

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to EWD 3 Training Course Part 44: Creating MicroServices with QEWD.js

Similar to EWD 3 Training Course Part 44: Creating MicroServices with QEWD.js (20)

More from Rob Tweed

More from Rob Tweed (20)

Recently uploaded

Recently uploaded (20)

EWD 3 Training Course Part 44: Creating MicroServices with QEWD.js