Algorithm

Diagram Core

In Diagram we created our own endpoint processing algorithm that combines endpoints and request data to created the API response. We refer to this algorithm as Diagram Core.

We are discussing of open sourcing "Diagram Core" and make it available as an NPM package so enthusiasts can easily created integrations for Diagram and possibly host their own version of the platform. If that sounds interesting to you send us an email explaining how our algorithm might help you on [e-mail].

How Data are processed

As described in Request Node section every endpoint starts with a request node. Data from the HTTP request are passed on to the request node and are processed as follows:

1. The request node processes the request (parsing Headers, Query Parameters and Body ).

2. After it's done, it triggers the connected nodes and passes the data to them.

3. In the same manner, its connected nodes are triggered, they process the data and pass them on to their own connected nodes and so on.

4. When it reaches a Response Node it returns the data it received with the status code the user have set.

Before running the algorithm Diagram Core gets all services data from our database such that JWT keys, MongoDB credentials, Stripe keys etc. If needed it initialises these services and before finishing termites them safely.

Simple Example

Node Settings

• Request: set to GET

• Response: set to a static response of {"hello": "world"} and a status code of 200

Evaluation

• A user run a GET request on this API with the default headers

• The request node will trigger the response node passing the query parameters which an empty object

• The response node ignores the passed parameters from response node because it set to static response

• That means that the endpoint will return {"hello": "world"} and a status code of 200

More Advanced Example

Node Settings

• Request: set to POST

• MongoDB: configured to a MongoDB instance with a email / password URI, set to get the user's document from the users collection

• Bcrypt: configured to Compare passwords

• JWT: configured to a secret key from the user and to Sign objects

• Response: returns status code of 200 or 401 accordingly

Link Settings

• Request → MongoDB: maps object to email property

• Request → Bcrypt: maps object to email property

Evaluation

• A user run a POST request on this API with the default headers and an email and password in http body.

• The request node will trigger the mongodb node and the bcrypt node

• The mongodb node will get the users document using the email from the request node (mapped from the request body using link settings).

• Then, it will trigger the response node with a 404 error and a message "User not found" if no document is returned from mongodb and will trigger the bcrypt node if there is at least one document.

• The bcrypt node has no all its dependencies processed and it is ready to go so it will compare the password from the returned mongo db document and the one the user provided in the HTTP request.

• If the two passwords do not match the response node will be trigger with a 401 error and a message saying "Wrong password". If the passwords match the JWT node will be trigger with the user document as a passed parameter.

• The JWT node will generated a token using the secret key the user had provided earlier and mapped that to an object with a token property (using the link settings again).

• Lastly, that object which has the form of {"token": "..."} will be returned to the user with a status code of 200.

Under the hood

There are two important functions in Diagram core. The is runNodesApi that processes the whole API with the help of the second function runNode which processes an individual nodes.

The runNodesApi function

1. Gets user services information from our database and decrypts environment variables on the fly

2. (Optional) Initialises user services (eg. connect to databases)

3. Calls runNode function with "Request node" as a parameter

4. (Optional) Flushes user services (eg. close connections to databases)

The runNode function

1. If node has already been processed OR has a missing dependency node OR has a blocking dependency node, we skip the node

2. Maps results from connected nodes to source ports

3. It processes the node with parameters from connected nodes and with the node settings and mark the node as processed

4. Then maps the results to the out ports of the connected nodes

5. And lastly, for every connected node we runNode again