How Radar Relay is Built

Users have asked for more information on our architecture. Our infrastructure, tech stack, and some specific beta details are described below. Warning: technical jargon ahead!

Infrastructure

Google Cloud, Kubernetes, Travis, Tick

The server and deployment infrastructure for Radar is powered by a provider agnostic Kubernetes framework. This allows for us to scale rapidly when the traffic spikes and significantly mitigate risks associated to deployment orchestration. All of our backend services are stateless and can be scaled independently without cross-instance state management and draining, allowing us to react to load and rollout updates easily.

We are using node.js and eventloop monitoring via the TICK stack allowing us to graph our instance load down to the specific method calls and how long they block the event loop.

Radar — Monitoring Dashboard

Lastly, for our Blockchain infrastructure, we host several custom Parity RPC nodes for certain backend actions along with utilizing Infura. We’d like to recognize Infura as they have been instrumental in supporting our beta! They provide an excellent service!

Tech Stack

Typescript + Øx.js

Both our backend and frontend codebase utilize Typescript, a strict syntactical superset of JavaScript. Typing and schema validation are critical in the design and architecture of a platform that deals with conversion and relation of many different abstractions of a single type. In the case of Radar Relay, we have many tokens that implement the ERC20 standard definition of an Ethereum network token and many orders that extend the Øx definition of peer-to-peer orders.

Using Typescript, we can ensure that strict typing is followed throughout both the backend and frontend, meaning, if a variable is declared to hold a string, it’s value will only ever be of type string.

Typescript’s implementation of Interfaces allows our codebase to have one reference to the base schema definition for objects. With Øx.js object interfaces, object schemas can be defined once and any instance of an object that extends or inherits that interface is guaranteed to have the fields defined in the interface.

Server-side Øx.js Wrappers

In addition to strict typing, implementing our backend in Typescript enabled the use of the Øx.js library. This means that SignedOrders are validated in the same manner as any other dApp that implements the Øx.js library, providing a consistent and stable validation across all applications that use Øx.js. The Øx.js library includes standard types that we can use without implementing the types ourselves, again, providing a consistent and stable definition of the types.

In addition to interfaces provided by the Øx.js library, interaction with the Exchange and Token contracts are abstracted away as well.

Server Side Web3

In order to utilize the Øx.js library on our backend, we wrote custom wrappers around the web3-provider-engine library. These libraries wrap the interactions with JSON-RPC and Web3 communication so we can communicate with the Ethereum blockchain similar to how users interact with the Ethereum network with browser Web3 providers.

Websockets

To stream data, the backend provides a websocket endpoint for clients to connect to, that streams changes to the peer-to-peer order book for the token pair that the client has selected. This ensures that clients receive new peer-to-peer orders as soon as they are submitted. This reduces the bandwidth requirements versus the client repeatedly polling an endpoint. We scan orders on the backend to check for order state changes and broadcast these changes to the client immediately to mitigate stale orders.

Frontend

As mentioned above, the frontend utilizes Typescript. In order to build a fast, lightweight, and efficient frontend, we implemented a custom Typescript based Vue.js framework. To deal with state management, we used Vuex, but created a custom wrapper around it in order to have strongly typed state.