Introduction

SOAJS API Gateway is a unique microservice that offers multi tenant authentication and authorization in addition to service discovery and mesh. Here is how the gateway handles the external and internal communications.

External request

All requests goes through the gateway where many things gets checked based on how you configure authentication and authorization as well as many other capabilities. The gateway will augment the request with extremely useful data and proxy the request to your microservice. check out middleware for more information Middleware

Internal request

Internal requests can be configured to go through the gateway and back to the designated microservice where you can whitelist internal communications, check out Configuration. You do not need to worry about awareness among the different microservices. The Gateway takes care of this.

Internal requests can also be configure to go directly between microservices and take advantage of SOASJ mesh. You do not need to worry about awareness among the different microservices. The Gateway takes care of this.

Benefits & Features

Self Awareness

The Gateway's main functionality is to provide awareness among the deployed microservices. The Gateway also sends heartbeat checks on a regular basis to all registered microservices. If any of these services is down, the Gateway will know and will notify you immediately.

You can have multiple deployment of the Gateway, should one go down, the others remain functional and your deployment remains accessible and working. SOAJS Gateway also distribute the load on the services; if you have 3 gateways where each gateway forwards requests to 3 instances of a service, then your cloud performance will highly increase and traffic handling becomes faster.

Request Handling

Before redirecting to the requested service, the API Gateway checks if the service is alive and running. If a service is down or does not exist, the gateway will return a message back to the sender without crashing. When a new service is created or added to the cloud, the gateway will detect its presence. All requests to this new service will then be forwarded.

The API Gateway runs on port 4000. To request a service in the cloud, simply add the service name after the port number as a path parameter. To request a specific API in that service, type the route path after the service name. Ex:

# CURL -X %method% http:// %controller host% : 4000 / %service name% / %route path% /
CURL -X POST "http://127.0.0.1:4000/oauth/token"

The above example calls SOAJS's API Gateway, then requests the oauth service and route token.

Load Balancing

SOAJS provides the ability to deploy microservices in High Availability mode. This means that you can replicate any microservice you wish to deploy. The Gateway redirects requests to designated service in each environment, and while doing that, if there are multiple instances of the same service, it implements a round-robin distribution on these multiple instances and offers the ability to load balance the traffic arriving to the cloud. This is approach lowers the load that a service should handle.
Consider having 1000 requests arriving to URAC service and you have 4 replicas of URAC with only 1 Gateway, then at peak time each instance of URAC will handle 250 requests, if you have 2 gateways, then each URAC instance will handle 125 requests .... etc.

CORS

SOAJS Gateway also provides support for CORS (Cross Origin Resource Sharing).
Enabling CORS allows different domains to communicate with SOAJS via its gateway to post and pull resources without having to deal with "cross-domain" issues and by simply using the standard methods: GET - POST - DELETE - PUT etc...

Cookies & Sessions

SOAJS Gateway also parses cookies and determines if there is an associated session. Sessions are capable of holding custom data on the server side level and minimize database calls to the database for faster request handling.

SOAJS sessions are capable to support logged in and anonymous users request as well as merging anonymous sessions with logged in users when needed

Ex: systems that provided anonymous shopping carts then merge these carts to users who create accounts upon checkout.

Security

All requests to microservices pass through the Gateway therefore these requests are being masqueraded since the URL schema looks like controller_ip:4000/serviceName/serviceAPI and there is no need to expose the service port directly thus no service can be invoked by calling its port directly when using cloud deployment mode.

The Gateway detects and parses the access_token provided by oAuth to determine if you are logged in, decrypts key from headers and lookup their corresponding tenants. This also allows it to load the Access Levels of these tenants and determine if the request is allowed to be forwarded to the desired service, API or if it should be blocked.

Since the API Gateway is capable of fetching the tenant & package ACL, the tenant custom Configuration ( Provisioning ) and the logged in User Record, profile and custom Access Level information, prior to forwarding the request to the desired service, it injects this information in the headers then it forwards the request to the that service.

Browser not supported