App Launcher Pattern

Microservices gained popularity for a reason. Building monoliths is expensive in every sense of the word – creating them is labor and risk intensive, and maintaining them becomes the quicksand you throw your feature requests into. With a microservices architecture, applications can focus on one task and be swapped out or iterated on without the jenga-like consequences that come with a monolith.

If our target monolith is one app to rule them all, we can take that concept into its own microservice – or application launcher. On the surface, the UX gains are an immediate improvement. Rather than have our end user search for a collection of shortcuts on their desktop or taskbar, they can start one application that will give them access to a predefined collection of apps. But this is just scratching the surface.

OpenFin applications can be built and deployed just like a typical web application. As an end user of a web app, I can create different app “sessions” by opening a site in different browser windows or tabs, and isolate their sensitive information with things like incognito browsing. As an app developer, pointing your end users to different versions of your app for either A/B testing or user demand is as easy as hosting multiple versions. This means we can do the same on OpenFin.

Session Isolation and Versions

The entry point for your application is its Application Manifest – a fully configurable JSON file you can learn more about here. In the runtime arguments, you can define your application’s security realm. You can think of a security realm as a defined collection of OpenFin applications. Just like opening a browser window in an incognito session will isolate that browser from the stored cache and cookies, a security realm on OpenFin creates its own private storage. Applications can be launched in the same security realm and share this information or assign random identifiers for true isolation.

While security realms can help you isolate multiple instances of the same application, giving users access to a previously deployed app or slowly rolling out your changes is even easier. Each application takes a url to launch, so either dynamically generating the content for the user or simply hosting different asset versions will get you there. Particularly when deploying to an internal datacenter or limited user base, the cost of hosting multiple versions is nominal.

Example

In our latest webinar, we touched on these concepts, while demonstrating some of the other ways to customize user experience. Example code can be found here or check out the video below: