In 2014 we created Reactive Trader®, a trading SPA (single page application) to allow our consultants to collaborate and show off their skills and in doing so raise the bar right across our differing practices. We’ve just rebuilt the platform from the ground up; and I’m excited to announce this series of blog posts that will go into depth on the new client side architecture. We’ll take you from the lower microservice based layers right up to the modular UI built using the latest technologies
We’ve built the client using purely open source components: ECMAScript (with babeljs.io), React, ESP, AutobahnJs, SCSS and Webpack to name just a few. The client can run in a browser or, for a rich desktop experience, in OpenFin, a secure container for the financial industry.
So what is a trading SPA?
A SPA refers to a single page web application. A trading SPA is somewhat different from a traditional SPA. When we think trading SPAs we’re thinking:
- Real time push based data
- Functionally rich
- Low latency, highly performant and resilient to network issues
- Always connected
- Open all week or more
- Built by many differing teams (thus modular)
- Constantly evolving over a number of years
- Rich integration with other applications (e.g. excel, the desktop)
- Reliable, maintainable and supportable
- Easy to deploy
The recent evolution in web technologies have made the above requirements viable in a space recently dominated by desktop-only technical stacks, as such that’s what we’ve used.
Tech Stack & Application Layering - a bird’s eye view
We host the app in either a browser or desktop container. We use React for the views, ESP to handle models (i.e. state), services expose push based backend data using Rx, and we connect over the wire using AutobahnJs.
We’re going to dig into these layers in more depth over the coming weeks so check back for updates to this blog series. We will, however, discuss bootstrapping, a small but important aspect that brings it all together.
It’s important to mention bootstrapping, which is the application's startup sequence. Too often this area is overlooked resulting in hard to retrofit concerns that get hacked in at a later date. Let’s point out some issues you may face without a reasonable bootstrapping abstraction:
- Odd race conditions between loading components
- No obvious place to wait until reference data loads before starting models and views
- No obvious place to build out on demand module loading
- No obvious place to initialise core application services
- No way to configure or swap out system services that may differ depending on the user's permission, hosting container or perhaps even the current device
The bootstrapper isn’t a complicated mechanism as it simply orchestrates the startup of core layers, components and UI.
The diagram below shows the bootstrap sequence in Reactive Trader® Cloud GUI.
We wait for the DOM to become ready, start services, connect the messaging layer, start models and render the views. From a runtime perspective our models are hot and ready by the time the view is rendered. From an architectural perspective we can grow out our various layers and be reassured our clean isolation and startup sequencing will allow us to expand the system without breaking existing functionality.
Where to next?
Over the coming weeks we’ll be adding articles to this series which deep dive on the above layers. In the meantime checkout a live demo of the app and for a more in depth look get the code. If you have any questions or find a bug, feel free to submit an issue on GitHub or, even better, submit a PR!