In Part 2 of our Anatomy of Finsemble blog series, we talked about what made Finsemble tick. If you took an x-ray of Finsemble, you might observe a “skeleton” made up of two pieces called the Distributed Store and the Router (see above image).
Router Service
The backbone of Finsemble is the Router Service. The Router Service is a hub that passes event messages between windows and microservices, enabling coordination between all components. At any moment, messages are zipping back and forth between components, like a high speed network running right inside your application. 
The Distributed Store
The Distributed Store itself is built on top of underlying messages transmitted through the Router. To understand the Distributed Store, think about how modern frameworks like React work. In React (and other JavaScript web application libraries) applications track data and business logic using an entity called a store. If you squint hard, stores are like a database—a central location that stores data (get it?). The store is a really useful concept because it allows many UI pieces to sync off of a single piece of data.
We realized that we could use stores to simplify the n-connection problem inherent in multi-window applications as well, converting a many-to-many environment into a many-to-one environment. Instead of each component connecting to every other component, we can program components to connect to a centralized store. Repurposed this principle, we created the Distributed Store to abstract away the n-connection inter-window problem.
The Distributed Store is awesome. Here’s why.
The Distributed Store reduces complexity by operating as a central repository. This reduces the number of connections that windows need to maintain. The Distributed Store hosts business logic which can be invoked by any window that it’s plugged into. This lets the store synchronize state across window boundaries. Multiple windows can share data, yet remain loosely coupled. Each window now only needs to be aware of a data model, not all the other windows. This is elegant because no one window ends up with an explicit dependency on any other. It no longer matters if window B starts up before window A, or window A starts up before window B. The Distributed Store allows multiple windows to become components of one large, overarching app.
There’s a final critical element that is important to understand about Finsemble’s architecture—the very base of the iceberg—configuration. Finsemble is designed to be inherently configurable because of one simple fact: you can’t build a huge system and hard code everything. Large systems need a place to manage things logically: a way to organize your application. That’s Finsemble’s config. Config may seem like a simple problem, but it’s not. Finsemble’s config can be assembled from multiple pieces, allowing you to organize your configuration logically, and Finsemble’s config is dynamic, so your application can adapt to entitlements, environments, and preferences. This is why we say Finsemble is a config-driven, not a code-driven, platform.
Microservices at Work: Components
So we now understand the nuts and bolts of Finsemble. As I mentioned earlier in the article, the goal of Finsemble is to provide an intuitive, functional workspace for end users. Now that we understand that microservices are driving your components, let’s pop back up above the surface of the water and get a picture of how the microservices empower users in their day to day tasks:
- The Drag and Drop Service shares data between components with a simple drag and drop action. Users can quickly move data between two components.
- Similarly, the Linker Service can keep data synchronized between two components. By setting two components to the same “channel” (color), a change made to one component will propagate to the other.
- The Hotkey Service registers hotkey combinations and their respective handler functions (regardless of which window the end user currently has focused).
- The Search Service provides federated search results. This provides actionable, Spotlight-esque search functionality.
- The Docking Service allows component windows to snap, dock, and group themselves together. This gives users total control over how they organize their screen real estate.
- The Workspace Service gives the user a persistent experience. They can save the state of components—both window position and the component’s internal data—and restore that state between sessions. Users can easily save and relaunch their desktop configuration.
And, with all these processes acting in concert, the Logger Service provides necessary support for debugging. Just using the Chromium debugger would require you to have many different debug windows open and mentally map the times of the logs. It’d be like trying to find an ant in a house of mirrors! With the Central Logger, there’s a unified place to view logs, with synchronized timestamps across all components and microservices.
Because Finsemble delivers all this out of the box, developers don’t have to build this infrastructure. We’ve already thought about and built tools to answer all of the n window problems. You’re free to deliver the application that best fits the needs of your users.
