Introduction

Some of the SOAJS Gateway features are:

handle the awareness among the micro-services
monitor the health of all the registered services
redirecting the requests into the appropriate services
decrypt cookies from logged in members requests

In the previous examples, a request to a particular service must be sent to the port that that service is listening to.

However, the controller alleviates this issue. Instead of worrying about ensuring the correctness of the service port number,

it is sufficient to direct the request to the controller's port number, while specifying the name of the service and the API being called.

Service Exploration

To turn on the gateway in a development environment you just need to start the environment as follow

Controller Installation

sudo soajs services start --env=example

The gateway for environment example runs and listens on port 20000. Its maintenance port is 21000.

The gateway can be accessed, from the local machine, using the following URL http://127.0.0.1:20000.

Perform a heartbeat check on the gateway to monitor its status:

Controller Heartbeat

curl -X GET "http://127.0.0.1:21000/heartbeat"

The following response indicates a healthy functioning of the gateway.

Controller Status

{"result":true,"ts":1425054123486,"service": {"service":"CONTROLLER","type":"rest","route":"/heartbeat"}}

Using the Gateway

Previously, when calling a service API, a request should contain the port of the service, followed by the API's name.

A problem might arise when the number of services increases.

The gateway alleviates this problem by aggregating all the calls targeting the services registered, and then redirecting each call to the destined service.

Consider an example where a call is made to the testGet API of the example01 service. The service listens on port 4021.

The following code snippet lists two requests. The first requests directly calls the service using its port.

The second request, on the other hand, calls the service and its API, through the controller, where the latter takes care of redirecting the request to the destined API.

Controller Heartbeat

# Direct request to the example01 service
CURL -X GET "http://127.0.0.1:4021/testGet?firstName=John&lastName=Doe"
# Indirect request to the example01 service through the controller
CURL -X GET "http://127.0.0.1:20000/example01/testGet?firstName=John&lastName=Doe"

Both commands invoke the same API of the same service. However, the controller alleviates the problem of memorizing the port number of each service.

Evidently, the controller has much more important and delicate tasks than solely redirecting calls to their appropriate services.

For further information, the Gateway section provides detailed explanation about this service and its tasks.

Browser not supported