Finsemble’s What
Before we dive deeper, let’s answer a simple question: what is Finsemble physically? The easiest way to think about a Finsemble application is that it is a “site.” The site that is being displayed is composed of many pieces. Each piece—chart component, toolbar, microservice, config files, API, etc—is really just a web page, an “asset.” These pages, or assets, are all served from an HTTP server—like a website. Each piece is displayed by a browser; in our case a lightweight, frameless Chromium window.
The thing that’s different from the web paradigm is that Finsemble shows multiple pages simultaneously, and arranges them directly on the desktop. Imagine if you opened a bunch of windows in your web browser and scattered them across your screen. One window contained a toolbar, so you made it really thin. Another window contained a menu. A few more windows contained content from different websites, or your firm’s portal. Now create the intelligence necessary to launch them at the right time and remember where you put them; make some of them move; make some fixed; make some ephemeral.
At its heart, Finsemble is a platform designed to create a modular, multi-window application. However, once you have a set of independently-executing windows that span memory, process, and trust boundaries with many-to-many connections, things get complicated. Before long you run into the “n window” problem.
Finsemble’s Why
Let’s explain.
Imagine a tin can phone: two cans connected with a piece of string. Maintaining the relationship between phone A and phone B is pretty easy. But if you wanted to have a tin can conference call, things would get tangled up quickly—each can would need to connect to every other can.
Similarly, as more and more windows get added to an application, the complexity of the app sharply rises. If each component must maintain a connection to every other component, then each app ends up maintaining n * (n – 1) connections.
Now what if you had to code all of these connections by hand? Dependencies—even circular dependencies—emerge and multiply. Complexity increases exponentially and you soon realize that you need abstractions and a framework to address a series of questions raised by the n connection problem:
- How can you synchronize state between windows when you don’t know which windows a user will pick?
- How can you debug when you could have 50+ processes running simultaneously, each with their own console?
- How can a hotkey register an action when the keystroke occurs in a different window?
- How do you handle storage when every component wants to open its own connection back to your server?
- How can you handle resource allocation when a user can open an unpredictable number of windows?
The How
Each one of our microservices was designed to address one of the questions raised by the n window problem. Microservices form the vast majority of what Finsemble actually is. Always working, supporting the things you see from just below the surface.
A microservice in Finsemble is a JavaScript module that provides capabilities to components or other microservices. Microservices themselves don’t have any UI; they run unseen in invisible windows. You interact with the microservices through corresponding client APIs, e.g., the Linker Client interacts with the Linker Service, the Window Client interacts with the Window Service, etc.
We’ll return to the microservices in a bit, but first let’s see how microservices manage to communicate and coordinate in Part 3 – The Nuts & Bolts.
