Gatekeeper router design

This wiki page presents the relevant details of the design and implementation of the Router.

Configuration

The Router component is configured with the routes shown in @Fig:routes.

base_path: /api/v3
paths:
  /packages(/?|/*):
    site: http://tng-common:5200/packages
    verbs: [ post ]
    auth: true  
  /slices(/?|/*):
    site: http://tng-slices
    verbs: [ get, post, put, delete ]
  /policies(/?|/*):
    site: http://tng-policies
    verbs: [ get, post, put, delete ]
  /slas(/?|/*):
    site: http://tng-slas
    verbs: [ get, post, put, delete ]

With this configuration, POST requests to /api/v3/packages will be passed (e.g.) to the component deployed at http://tng-common:5200/packages, requiring authentication.

This is a very flexible, powerfull and simple approach for defining our needed routes. For example, one can require bearer authentication only for the delete HTTP verb:

...
    verbs: [ get, post, put, delete: {auth: bearer} ]
...

Implementation

For this component we have adopted a layered design, instigated by the rack framework. This framework is an interface to the application server in ruby and is very simple: any ruby object can be a rack application, as long as it implements the call method, receiving a hash with the enviroment (calling URL, parameters, etc.). Well known examples of its usage are the sinatra and ruby-on-rails frameworks, which both sit on top of it. @Fig:rack_app shows a generic diagram of such application.

Each rack application can do some processing (e.g., calling an external component, like it is exemplified in the request of @Fig:rack_app) before calling the next application in the rack or just forward the call (e.g., like it is exemplified in the response of the figure below).

These applications can be layered, to provide more complex features (see the figure below).

In the case of the Router, the following rack applications are used:

1. TangoLogger: logs requests into the $stderr;
2. Instrumentation: instruments every request, regitering the time each one takes (unless the environment variable NO_KPIS is set);
3. Auth: authenticates every request (unless the environment variable NO_AUTH is set);
4. UpstreamFinder: finds which upstream to address, based on the URL of the request;
5. Getter: processes GET requests, by far the most common ones;
6. EmbodiedMethod: processes POST, PUT and PATCH requests (those potentially having a body);
7. OtherMethods: processes remaining HTTP methods (for this version, DELETE, HEAD and OPTIONS);
8. Dispatcher: the deepest level rack application.