March 22, 2024
Enhanced Deployment Flexibility with OpenFin's Fallback Manifests
By Steven Mocarski, OpenFin CTO
At OpenFin, we make digital work frictionless and delightfully productive, wherever you are. While we are coming out with some exciting new capabilities to make your OpenFin content usable directly in traditional browsers, many customers today enjoy the additional capabilities that come from using the desktop runtime. One challenge developers face when deploying to desktops they do not control is that policies may be quite different from group to group. To address this, we quietly introduced Fallback Manifests in RVM 9 — a feature designed to provide flexibility and control when deploying to target desktops that may require variations in your application configuration.
The Challenge for Complex External Deployments
Variation in customer desktop configuration due to customer preference or policy concerns can be a headache for developers. Inside your company, you have one set of standards and you can build to this but what if you need the application to run on a diverse range of configurations? For example, a given runtime may not yet be available or an old runtime may be restricted for security reasons. A new version of application features may be unreachable or prevented from starting for a variety of reasons. Fallback Manifests allow platform teams to specify a hierarchy of preferred manifests such that if a user's system does not support the primary version, the RVM automatically selects the next best available version. This feature simplifies your rollout, even in the most complex situations, ensuring compatibility and performance across different environments.
How to use Fallback Manifest as Part of your Deployment Strategy
Integrating Fallback Manifests into your deployment strategy is seamless. By specifying alternative manifests, developers can ensure their applications always run on the optimal runtime version. Consider the following example, which demonstrates how to specify fallback versions for an application targeting runtime version 36, with alternatives for versions 34 and older:
{code}
If the application url could not load for any reason (404, the required runtime version was not available, etc), RVM would fallback to the https://blog.openfin.co/v5/headphonesOn.json
manifest referenced above, which would look similar and perhaps use a different runtime (v34 in this case):
{code}
Note that we don’t need a fallback manifest block in the https://blog.openfin.co/v5/headphonesOn.json
manifest above since we have one in the latest (first) version above. As a side note, were a fallback manifest listed here, it would be ignored since we just use the primary (first) manifest to determine fallbacks (they are not recursive). As with the v6 example, were v5 to fail to load for any reason, we would fallback to the next manifest url, v4 in our example and so on.
This configuration ensures that the RVM selects the best compatible version, streamlining application deployment across varied runtime environments.
Migrating Cache Across Versions With Ease
In the example above, we use a static URL for our "latest" version of our example headphonesOn app and anyone updating from version v5 to v6 of our app (moving from runtime v34 to v36 in this example) would have their cache migrated normally, regardless of their RVM version or whether or not they use fallbackManifest option.
The first time a given manifest URL is run inside a runtime, the RVM will check to see if the cache needs to be migrated. This is important because without migrating the cache, something like user settings stored in the local IndexedDB
would be lost when changing runtimes. Prior to the release of fallbackManfiest
, the RVM would only migrate the cache if the manifest URL was unchanged, so you could not have a versioned URL of your manifest for upgrades. Fallback manifests helps here as well because it allows you to explicitly identify these fallbackManfiest
as the same app, and the RVM will trigger migration when you want it to.
Cache migration is a big topic and we have some exciting things in the works to make this even easier coming later this year.
The Bigger Picture with OpenFin
Fallback Manifests are part of OpenFin's broader toolkit designed to empower developers. Our platform's capabilities are aimed at simplifying the deployment and management of desktop applications at scale, allowing businesses to deliver complex, high-performance platforms efficiently.
OpenFin's commitment to development flexibility and efficiency is embodied in our continuous platform evolution, with Fallback Manifests highlighting our dedication to solving modern deployment challenges. We encourage our developer community to engage with us, sharing insights and questions as we forge the future of platform development together.
Enjoyed this post? Share it!
Related Posts
All Posts ->Featured
ING Integrates OpenFin for Salesforce to Optimize Workflows
Thought Leadership
Featured
OpenFin + AWS Bedrock
Thought Leadership