Finsemble: Future Of Desktop Applications

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.
  • The Container provides Chromium, a browser engine to run your application across any operating system. This browser does not have a location bar, tabs, bookmarks or even menus; however, it has the same underlying technology as your actual browser - a V8 engine for running your JavaScript code and Blink/WebKit for rendering your HTML.
  • The Container provides an API for interfacing with the operating system. Developers interact with the API through JavaScript. The API can do things like spawning new windows, interact with the system tray, trigger notifications, etc. In theory, the entire operating system can be exposed through the API, although in practice the Container provides limited access, so that developers can benefit from the basic browser sandbox model.

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:

  1. V8/WebKit
  2. Chromium
  3. Electron
  4. OpenFin

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

In a multi-window HTML5 application, each window runs its own browser "context". That is, each window contains its own HTML and runs its own JavaScript. Each window has its own DOM, its own stack, and its own globals, modules, static space, scope, event notifications, etc. This automatic containment is both very basic and incredibly powerful. This allows us to naturally organize an application into components. Running in its own window, each component can safely rely on having an independent context - its own HTML page. It does not need to contend with other components or yield to a coordinating architecture.

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.

Assembling windows into a single application does require a paradigm shift and a little bit of architecture. A multi-windowing HTML5 environment is essentially a distributed system. Each window is its own application, running in parallel with all the others. Distributed systems are traditionally applications that run on different servers and coordinate their efforts via a network. Our distributed desktop environment is a perfect analog. Distributed systems communicate using messages, reacting to them in an event driven model. The solutions employed for distributed systems turn out to be a perfect fit for JavaScript which is inherently an event driven language. A Finsemble application runs components in parallel, each with its own context, and coordinating over a network (e.g. the OpenFin IAB) to operate in concert as a single application.

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

Out of many, one. Each microservice is accessible via a JavaScript API. By leveraging these microservices, a developer can assemble multiple components that behave in an orchestrated manner to become a single application.

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

Essentially, any user who could benefit from an application that allows them to do more than one thing at a time is a potential candidate for an application built using Finsemble. Likewise, any HTML5 application that can benefit from multi-window support can be build on or integrated into Finsemble. Once a developer wraps an HTML5 + JavaScript application within a Finsemble component, it has full access to microservices capabilities under the Finsemble umbrella.