The Build Process

JavaScript build tools were designed with single-page applications in mind, and they, by and large, work very well for that purpose. Finsemble, however, is designed with multiple windows in mind. Unfortunately for us, there aren't any tools available for building N single-page applications that work together.

Because Finsemble is working at several levels of the application stack, the build process uses two types of tools:

  1. A task runner (Gulp-4.0).
  2. A module bundler (Webpack).

Gulp

Gulp is one of many JavaScript task runners available. We're using version 4.0, which allows for tasks to be run in series or in parallel. It's currently in alpha, but we've found that it's generally reliable for what we're doing. Gulp does several things for you:

  • Starts the node server that serves files to OpenFin.
  • Launches the OpenFin runtime.
  • Copies static files from ./src/ to ./built/.
  • Starts watchers that will trigger Webpack to rebuild your services, clients, and components when their source changes.

Webpack

Webpack is one of the best module bundlers currently available. In the Finsemble build process, Webpack is responsible for:

  • Bundling your custom clients and services.
  • Building any component that requires a build process (e.g., React components).

Diagram


Application Start-up

Finsemble is built on top of the OpenFin runtime environment. When OpenFin is launched via npm run dev, or via an installed application icon, the application start-up begins. Locally, it follows the build process. Remotely, it all happens when the user double-clicks the icon.

The process flows like this:

  1. The application checks to see if it has the latest version of OpenFin Runtime (using the OpenfinRVM).
    • If so, proceed to step 2.
    • If not, update OpenFin Runtime.
  2. After the application has the proper runtime, it looks for the OpenFin manifest (i.e., starting config file) and starts your startup_app. The initial startup_app is the Service Manager, within the Finsemble application, that loads within a hidden window.
  3. The Service Manager spawns all of our services as hidden HTML windows.
  4. Once all of the services are ready, the Workspace Service begins spawning windows.
    • Menus are spawned and hidden. They are later moved to the appropriate position when called upon.
    • Toolbars are placed on every monitor.
  5. The workspace is loaded.
    • If there are workspaces found in storage, the most recently used workspace is populated on the screen.
    • If no workspaces are found, a default workspace is loaded.

Further reading

To understand how Finsemble solves the problem of handling many-window applications, proceed on to Process Splintering.

To better understand what happens after start-up, proceed on to Configuration.

To learn more about events that happen once the application is started, check out Lifecycle Events.

For more on modules, why you should use them, and what they are, see this blog post.