In April 2014 we gave a talk at React Conf London on Reactive user interfaces and open-sourced Reactive Trader®, a demo app we used to demonstrate the different concepts we highlighted in the talk. The talk was focused on UIs so we put most of our effort into the front-end and built a very simple monolithic backend to simulate the different flows and failure scenarios.
To launch Reactive Trader® in our demo environment, click here.
In this post I’m going to give an overview of the project and to start, the design principles we’ve been following:
- we want anybody to be able to clone our repository, build and run the whole thing easily on Mac, Linux or Windows.
- the front-end should use modern web tooling and libraries, which are fit for purpose to build a responsive trading front-end (ie. event-driven, high rate of updates, etc) but also easy to develop and reason about
- the backend should be distributed to allow different components to be developed and deployed independently
- the overall system should be resilient: middleware can fail, services can fail, things can get disconnected, started in different order, etc. The system should be able to run in different degraded modes and recover gracefully
- services should be scalable, independently of each other
- the overall system should be event driven: the clients and services exchange messages over a full duplex pipe, instead of restricting themselves to only request-response style interactions
- the whole system should be built using exclusively open-source libraries
- deployment should be fully automated and able to target a public cloud environment, a private cloud environment or an internal infrastructure
High level architecture
Reactive Trader® Cloud is a demo client-server FX trading application. The backend is composed of a set of services which can be scaled, deployed and upgraded independently. Instead of using HTTP, the client connects to the backend using Websockets and since we have a number of services, we decided to use a messaging gateway to act as a broker: this allows the client to establish a single connection to the backend and the broker is used to route messages to the correct service instance or to the correct client. The backend also uses an event source architecture: all events corresponding to the lifecycle of reference data and trades are persisted to an append-only event log.
In terms of continuous integration and deployment, our build server produces docker containers for each server side component and publishes them to a docker registry. We also have a suite of deployment scripts to build a kubernetes cluster and deploy a full environment, or individual components, to a cluster. How long does it take you to provision a new development environment from scratch for your platform? Here it takes less than 30 seconds. If you want to learn more, we gave a talk recently at a Google conference to showcase our approach to Cloud deployment with Kubernetes.
The app is deployed to our Kubernetes cluster, you can have a look here.
In the next few weeks we will publish a series of blog posts focusing on specific aspects of the project, including:
- Client Architecture with ES.next, React, Webpack, RxJs
- Cross Platform .Net Development with .NET Core
- Event Sourcing
- Web Messaging
- Always Connected Apps in a Microservice Environment
- Desktop Client Support with OpenFin
- Failover and Resiliency in a Microservice Environment
- Deployment with Docker and Kubernetes
Co-founder and Chief Technology Officer,
Adaptive Financial Consulting