GreenKey is a voice-driven collaboration platform for financial market participants. We are working to replace the industry’s antiquated turret and telecom systems with a collaborative, high-throughput VoIP platform that enhances compliance and enables sophisticated data analytics and workflows. No easy task. To deliver on this, our team has been incredibly thoughtful about our platform architecture front-to-back. There is much to say about our back-end server processes and pod architecture, but the focus of this post is on the front-end and our recent decision to move from Java to HTML5 and OpenFin.
There are millions of developers and thousands of companies wondering today if they should make the leap to HTML5. GreenKey was in the same debate 12 months ago. I approach technology as a collection of advantages and disadvantages.
The main advantages for us are:
- A Java installable was not getting the job done; we needed zero install.
- We wanted to build once and run on any operating system.
- We could have a faster development cycle fueled by a vast and growing open-source ecosystem.
But the disadvantages of running HTML5 in a browser were stark:
- Many web browsers don’t support WebRTC, which is critical to our business.
- Browsers don’t enable real-time alerting or conservative use of screen real-estate.
- Inside a browser, we can’t interoperate with other applications on the same desktop.
Since these were all show-stoppers, we began looking at open-source HTML5 containers which let you run HTML5 outside of a web browser with an installed app experience. We quickly gravitated to Chromium, an open-source project from Google with nearly 10 million lines of code and averaging 5,000 commits per month. It is a beast! We were overwhelmed by the size and complexity of the project and felt it would consume too many resources for us to manage alone. Also as a startup, we wanted to stay focused on our niche of building an awesome voice-driven collaboration platform and partner with someone else who could provide support for the container. Enter OpenFin.
OpenFin provides an open-source HTML5 container built on Chromium - but designed specifically for the financial markets. They get it and they have no trouble keeping pace with those who run fast like us. At a high level, OpenFin increase security, provide native application capabilities and enable inter-application messaging. But as hard as it is to build a container, delivering the container to end-user desktops is far more painful because of the wide dispersion of acceptable operating systems and security policies at customer sites.
Building our own container with Chromium-based projects like Electron or CEF would have meant that we were assuming the task of installing our own container and keeping it updated across every financial institution. That’s not much of an improvement over having an installable app. OpenFin standardizes the installation process and gives us zero install through their secure, managed auto-update technology. They’re working directly with banks and buy-side firms to streamline the process so firms like ours don’t have to worry about deploying our own containers.
Perhaps most importantly, OpenFin’s container is now being used by most major banks and trading platforms for their own customer-facing and in-house applications. That means the container is being rigorously tested by development teams across the industry and that it has a level of attention and priority for upgrade that no bespoke container could have on its own. It also means that the GreenKey client is already default interoperable with all existing OpenFin users. With very little development effort, we can now implement context sharing and visual integration, even with applications written in native languages like WPF and Java.
We’re excited about our move to HTML5 and OpenFin. I’d recommend it to anyone who is building a real-time financial industry application. I’m confident it puts the GreenKey front-end on the best possible foundation now and in the foreseeable future.