Mercury - Gateway, Authentication and Statistics API - Specification

Mercury should be implemented as REST API Server, with functional requirements being:

  1. POST Creating account on LWS
  2. POST Signing in on LWS
  3. GET Receiving current data plan and avaliable services
  4. GET Receiving current account balance
  5. POST Updating account balance
  6. POST Updating password
  7. POST Subscribe to alert
  8. GET Receiving account statistics and usage of account's services
  9. POST Validating authentication header
  10. GET Getting the UUID from username

Except for given request, this service should realize the following features:

  1. This is basically the main part of service, the gate of all other services. This means that except of other requests, this app should send emails to clients with news update for their account(statistic and balance).
  2. Should be able to route and navigate to subdomains made for cloud storage, database and micro services hosted by Vulcan.
  3. Authentication should be checked by this part of LWS, meaning this service needs to generate token for user, that user will send to header, service will check if it is right and proceed to forward the request to further service.
  4. There should be a good algorithm for calulating how much data is used by given service(requests sent to Vulcan). E.g. Should not calculate with number of requests and instead should be done with number of responses
  5. Should manage the database created by Minerva system.

Centralized system

As this project is based on centralized system around this gateway, this gateway should be the only one communicating with clients and only one responsible for communication of other services. Basically, that means that a client can only send request to this gateway, and gateway will be the one who will respond to client. What happens in between user cannot see. This type of architecture is called SOA or Service Oriented Architecture. Modern times have microservices and lambdas, too, but they are mostly glorified services. The part we have is good usability for client and platform as a service. The reason why we do not use monolith architecture, ease of upgrade, control and technically(but we do not have similar services for now) reusability of codebase. Gateway is also a service, actually can be devided into 2 services, true gateway and user managment service, but I found it reduntant, as it will be much more complicated and it will have almost no benefits(users managment is very small functionality).

Routing

The most important part of this service is routing. As we said earlier that client can only communicate with this service, this service should route the request to targeted service. If you user says jupiter.lws.com/get, user indeed wants something from jupiter, but it will target gateway, gateway should send the request to whatever internal adress of jupiter is, wait for response and send it back to our user. The sequence diagram would look like this:

/assets/basic interaction

Except for routing Minerva, Jupiter and Vulcan, it should also route microservices created with Vulcan

Usage

We are open-source project, and we will not make profit from this, but just for demonstrational purpose, we will make payment system. Almost all SOA have pay as you go philosophy, where user pay for what he uses. It sounds cheap, but it gets really expensive. The idea here is to get data from vulcan about how much cpu/ram is container using, but also find a way to calculate how much trafic does that service created by vulcan uses. With all of this parameters, you should be able to calculate some nice price, add price for cloud storage and database, and you are good to go!

This is corse-grain solution, and I will definetely make it a bit better in next few days, i need to look at big picture for details and create diagrams for each use case, only then will I be certain

Creating account on LWS

url: lws.com/signup

This is straightforward request for creating account with username, password and email.

Signing in on LWS

url: lws.com/signin

This is also straightforward request for signing in with username/email and password. The response here should be a unique token that user can send in header in order to prove that he is authenticated. Tokens have a lifetime, but everytime a user sends a request, a token should be refreshed(it stays the same, just time resets).

Receiving current data plan and avaliable services

This get request will return a specification of data plan user payed for(database, cloud) and all of his avaliable services created by vulcan. The response should be something like:

{    "jupiter": "premium",    "minerva": "none",    "vulcan": [        {            "name": "service1",            "status": "offline"        },        {            "name": "service2",            "status": "online"        }    ]}

Receiving current account balance

url lws.com/balance

This request will return users balance, meaning how much money he has on account. A response is simple:

{    "balance": 1900}

Updating account balance

url lws.com/update_balance

In this request, just for demonstration purposes, a user can send POST request with money that should be added to his account. Request:

{    "money": 1000}

Updating password

url: lws.com/update_password

Post request for updating password by send old password and new password, although it has authentication header with valid token.

Validating authentication header

This will be used for internal purposes, but it should return users username if he is authenticated and token is valid, or error if not. This will be used for other services to check if a user is signed in.

Receiving account statistics and usage of account's services

This request will be a bit more robust as it should have nice statistics for each of the services, with response being like this:

{    "jupiter": {        "used": "3GB",        "avaliable": "9GB"    },    "minerva": {        "databases" : [            {                "name": "database1",                "size": "200mb",                "maxSize": "300mb"            }        ]    },    "vulcan" : {        "services": [                       {                "name": "service 1",                "cpu": "23%",                "ram": "12%",                "data": "304kb"            }        ]    }}

Basically returns the statistics for each service, this is current version of data, but will probably change

Validating authentication header - INTERNAL

This request should return UUID for given token, or null if such token is not regular or expired. The request body is:

{    "token": "TOKEN_HERE"}

And the response should be simple

{    "UUID": "UUID_HERE", // or null    "username": "USERNAME_HERE" // or null}

Getting the UUID from username - INTERNAL

This request is required for getting UUID for username. Simple request will containe json like this:

{    "username":"USERNAME_HERE"}

And the response will be UUID or null, similar to the request above.

Internal means that only internal services should be able to use this functionality

Sending emails

As I said, Mercury is mix of 2 services, the user managment service and gateway. The functionality avaliable to Mercury will also be sending user a bill with statistics and price for this month. It should also be able to alert users that subscribed to being alerted if price of montly payment goes above certain threshold.

Subscribe to alert

url: lws.com/alert?threshold=3000

This requests subscribes a user. User should get email alert if his montly bill is above threshold he put as argument.

Table of Contents