Finsemble: The Future of Desktop Applications
Twenty years ago, the browser became our best friend when it ushered in a bloom of information and access. HTML had finally made it easy to build graphical applications. CSS made these applications beautiful. Web delivery meant that product improvements became available to customers instantaneously and securely. Users now had instant access to beautifully designed, rapidly developed, secure applications, which they accessed through a single, simple, ubiquitous tool - our friend, the browser.
Despite our move to an Internet society, two decade later desktop applications still remain a part of our daily lives. This is particularly the case for professionals who are dependent on powerful applications for their livelihood as they spend most, or all, of their day engaged with desktop applications. Across many professions, we find examples of such individuals relying on their mission critical software tool:
- Designer - Photoshop
- Engineer - CAD
- Studio Engineer - DAW
- Film Editor - Avid
While we see this teaming of professional with tool across many walks of life, finance is the industry where the power application is truly ubiquitous. Many financial professionals use multiple power apps throughout the day which necessitates stringing windows across multiple monitors to allow them to have all their tools and apps available at a glance. The stockbroker with more monitors than eyes has become cliche to the point that it is the image that one finds after searching for "Stockbroker" on Wikipedia.
Our industry is a long way from abandoning the desktop app; however, there is good news! A new wave of technologies has recently emerged that extend the browser’s inherent advantages all the way to the desktop application. We have entered a "Desktop Renaissance".
The Desktop Renaissance
Since the emergence of the browser, HTML (now HTML5) has matured into a fully fledged application infrastructure. Along the way, it has revolutionized the way applications are built. With HTML5, we can deliver more functionality, faster, and within a rapidly expanding ecosystem. HTML5 has truly changed the way companies create and deliver applications but, until recently, its adoption had been limited to web and mobile devices. Ironically, the final frontier for HTML5 is the thing that many thought it would initially replace - the desktop application.
If you have downloaded Slack or Spotify, then you are already a participant in the revolution. These applications were not built in Java, .NET, C++, C#, Objective-C, Swift, Flex, Delphi or any of the other languages and frameworks that have been used to build desktop applications for the past few decades. These applications are built in HTML5. With a peek behind the curtain, you will find our old friend the browser, stripped down to its bare essentials and running inside what is called a "Container".
"Containers" provide the runtime environment that makes it possible to deliver HTML5 desktop applications. One way to think about a Container is it is the HTML5 equivalent of Java’s Virtual Machine (VM); it is an application that runs an application. To the user of course it looks, feels, and behaves like any other native app. To the developer though, the Container radically simplifies the process of building desktop applications.
The Container does several things for developers:
- The Container provides an executable (.exe) that can be launched by the operating system and saved on the desktop as a clickable icon. The executable’s behavior is controlled by a "manifest" which is configured by the developer.
Companies such as Slack and Spotify could not help but notice the advantages the Container approach provided. They had invested heavily in HTML5 technology, but ultimate success required staking a claim on their user’s desktop real-estate. It was critical for their apps to be on the desktop and launchable with a click. The Container concept allowed them to achieve these goals, with a single code base, while benefitting from all of HTML5’s inherent advantages.
OpenFin: A Secure Operating Layer
We now know that mission-critical desktop applications today are being built in HTML5. We recognize that the benefits of the browser - accelerated development, web deployment, sandbox security - can be realized within the desktop application. This is great but not enough. For financial apps, we must go an extra mile. We can boil down the specific needs for financial applications to:
- Performance - Spotify users are not opening a dozen windows across six monitors - but traders are! Web browsers are inherently designed to run one application at a time, in one window at a time (single threaded). The demanding finance professional is not going to sit around waiting for a page to render - so higher performance is required.
- Security & Compliance - Financial professionals (and the infrastructure and development teams who service them) operate under intense rules that protect the interests of investors and the firms themselves. We desire the inherent security benefits of the browser sandbox while at the same time we need to be cautious of APIs that offer unfettered access to the operating system - so a secure solution is necessary.
- Infrastructure & Deployment - Financial firms often service tens to hundreds of thousands of users. They require a deployment strategy that is seamless, automated, and manageable; one with automatic updates rather than requiring a user to constantly download new software - so we need a distributable application.
Thankfully, OpenFin offers a common operating layer that addresses the specific requirements of our industry. With five years of experience, OpenFin provides a thoroughly vetted, production quality solution that is already in use by financial firms. Built on an underlying Electron core, OpenFin provides an alternative - secure - API. They have significantly improved the performance and memory footprint of the runtime environment. The OpenFin development and build processes specifically address deployment and they have a roadmap for APIs that streamlines critical finance related issues.
Critical to Finsemble, the OpenFin operating layer also provides an inter-application bus (IAB) for transmitting messages not just between components within an application but also between various applications running in the OS. We will see that this bus provides the subtle cornerstone for building powerful desktop apps in HTML5.
Ready, Set, (Not Quite) Go!
We now understand the technology stack that will power our desktop finance app:
There is only one thing missing: the multi-window UX and UI Finsemble provides! Finsemble is the toolkit that enables full desktop UI development in HTML5; the last-mile of technology necessary to build your desktop app.
Containers provide essentially the same starting point that a browser provides - a blank page. You get a runtime to execute your code and some low-level APIs. Legacy environments, like .NET and Java, gave us more goodies; graphical "controls" such as dialogs, menus, and windows. They also gave us an IDE that magically provided stub code for wiring up those controls with business logic. We do not get the same head start with Containers.
In some sense, this is okay because cookie-cutter is not the HTML way. Much of what makes building apps in HTML5 awesome is we are not constrained by a single paradigm. HTML5 gives us complete control both over how we build components and how they look. This level of control lets us devise better user experiences. We also have frameworks (Angular, React, etc.) and toolkits (Bootstrap, Kendo, etc.) to do some of the heavy lifting. The only problem is these tools were not built with desktop apps in mind. There is a significant danger of misstep and compromise if we depend on existing technologies alone. Finsemble fills this gap.
The ability to have an application span across multiple windows is the most significant difference between a desktop app and a browser app. One complication is, in HTML, each window has its own program space (context). Frameworks like Angular and React were designed for single context and do not inherently deal well with multiple windows. We find that the single biggest compromise made when building HTML5 desktop applications is constraining the application to a single window. Developers often will build a simple browser application, slap it into a container and call it a desktop app. The problem with this approach is it represents a significant downgrade in user experience when the new app replaces a legacy application that stretched multiple windows across multiple monitors.
Once we recognize the need for opening and managing multiple windows within an HTML5 desktop application and the shortcomings of existing technology, we begin to understand Finsemble’s position in the technology stack. Finsemble provides:
- An architectural layer for managing the complexities of multi-window development
- Graphical controls that developers need to build desktop applications
- Ready made components, services and adapters strictly for Finance
E Pluribus Unum
Extending this idea further, the component-context paradigm allows us to easily "compose" applications. Components can be loaded from disparate sources and using heterogeneous technologies. For instance, Angular and React do not play well together - unless they are in separate windows. Components can even be loaded, in parallel, from multiple hosts. With Finsemble, one can truly compose an application from independent pieces. The multi-window paradigm not only improves user experience but it also enhances product development.
The following out-of-the-box microservices are provided by Finsemble to assemble multi-window apps:
- Window Management Service - Coordinates windows within one application
- Workspace Management Service - Saves and recalls window layouts across multiple monitors, with a provision for saving and restoring the "state" of each component
- Data Management Service - Creates singleton network streams and multiplexes those streams across multiple components
- Linker Service - Orchestrates communication between components in order to keep them in sync with each other
- Human Behavior Service - Creates a "net" to catch click & key events across all windows so they can be handled at the application level
- Event router - Provides event abstractions such as broadcast, peer-to-peer, query/response and publish/subscribe. Events are sent using an underlying transport such as the OpenFin IAB
A key feature that makes such coordinated applications possible is OpenFin’s IAB which allows for transmission of messages between windows, particularly between windows that cross domains. A second key feature is OpenFin’s implementation of process sharding. In Electron, each window is backed by a separate browser process. This creates a large memory footprint. An alternative approach (taken by NW.js for instance) is to share a single browser process across all windows. This creates the opposite problem - a CPU bottleneck. Process sharding allows a subset of processes to service a greater number of windows, providing an optimal balance of memory and CPU - critical for powerful financial applications.
The Value Proposition