Javascript

Closer look at the DNA of the OpenFin Platform API

Published Mar 23, 2020

Updated Feb 14, 2023

8 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

This blog takes a deep dive into the newly launched Platform API by OpenFin. After only a few days of playing around with the software, I realized just how much capacity it has and how many good features there are for developers. Ultimately, this robust set of features will significantly enhance your user’s experience.

Before I begin, let's start with a bit of background information on OpenFin!

Dictionary

API: Application Programming Interface OS: Operating System CSS: Cascading Style Sheets

What is OpenFin?

Openfin is a tech company focused on modernizing desktops, and accelerating innovation in the financial sector. Simply put, OpenFin is the Operating System of Finance! With this, you get the power you need, the freedom you want, and the security you must have.

The Problem

If you are in the financial sector, you know that it is very important to be able to visualize everything on one screen when interacting with multiple applications. We usually tend to arrange windows over and over, but that takes time, and our applications do not work with each other, nor do they share all data between them by nature. Most importantly, we have to try to make sure all of these apps are secure!

The Solution

Platform API of course!

What is the OpenFin Platform API?

It's a software that will help you build desktop platforms at the speed of light. The Platform API will also facilitate the work of creating a merged user experience across the multiple applications.

“The Platform API is for central architecture teams who want to provide web apps with a unified desktop experience and common look & feel.” - OpenFin Engineer

Key Features of the OpenFin Platform API

Layout management (e.g. window drag-and-drop and tabbing)
Customization of window look & feel
Styling via CSS
URL for loading the title bar window
Customization of all Platform APIs (behaviors)
Save and restore your window view.
Window level context (different from FDC3)
“Smart” Manifests to describe platforms via a single .JSON file

The Powerful Gridlayout

One of my favorite features is their grid layout. This feature has helped me reduce the amount of time it takes to develop an app. It can get pretty complicated to create dynamic grids that work with internal and external windows, by dragging and dropping. Now, if you see it from the end user point of view, this is an awesome idea, because the grid is customizable!

Now, I know what you are thinking. And no, you don't need to ask the developer to change the layout of the application. You, as an end user, can change the layout as well. This gives every end user the opportunity to have customs views of their apps that best fit their needs, and grow their productivity.

As a developer, I believe this is a huge benefit, since I don't have to worry about writing the code for this dynamic grid, nor do I need to worry about customizing the layout for each end user or client, which allows me to focus on the actual applications that will be used inside of the Platform API.

Because a Grid layout is not enough

The Platform API gives you the ability to power up your platform not only with custom layouts, but also with tabs! As a developer, I can develop my applications used inside of the platform with the assurance that they can be grouped together on tabs. And one of the coolest things is that you can customize them! If you are an end user of the platform, there are so many benefits here. E.g You can group the tabs by colors, where each color represents windows that belong to a certain group. This is huge. I have seen monitors of people working in the financial sector with 20 open windows and sometimes, users get lost in this. It's hard to manage what's going on.

Your perfect setup...always

So while working with the Platform API, I found out that you can save the current platform setup. This is an amazing feature. When working with dynamic layout, having to re-arrange things every time the code compiles can become very tedious. Now, imagine the benefits of this for the end users!

As a developer, you can easily retrieve the existing snapshot of your saved platform by using the applySnapshot method.

platform.applySnapshot(mySnapshot, {closeExistingWindows: true});

Thanks to this, you don't have to worry about losing the perfect setup that took you time to arrange. The setup will be always the same as long as you want to apply the saved snapshot!

Advanced workflows

The Platform API allows you to get the current context of your window. Thanks to this, you can easily save it into the platform's snapshots to re-use the context when the aplySnapShot method is called.

#The Core Now, let's take a closer look at the core of OpenFin’s Platform API and dive into some code examples. What is the core? It’s the manifest! I like to refer to it as the core because it is what carries all the information which constructs your Platform API project.

The manifest is located inside of a .json file AKA the app.json

#Let’s Get Started Let's create our manifest:

{
    "platform": {
        "uuid": "thisdot_platform"
    }
}

As you can see, this is the beginning of a new project using the Platform API. All you have to do is declare the "platform" object in your app.json.

Now let’s dive into the features to customize the application experience.

Customizing the Platform API Window

Customize your window's look and feel using css, and by adding defaultWindowOptions. You manifest will look as follows:

{
    "platform": {
        "uuid": "example_platform",
        "defaultWindowOptions": {
            "stylesheetUrl": "url-to-css-stylesheet"
        }
    }
}

##Take a look at this file to see what css selectors are available in the Platform API.

You can also replace the default windows that come with the Platform API. To do this, specify the url property as a window option in your manifest. You can import your custom HTML as follows:

...
"defaultWindowOptions": {
    "url": "url-to-html-file"
}
...

##When working with your custom window, all you have to do is consider the following:

This HTML file must specify a div component with the ID layout-container where you want the layout to be rendered. This will ensure that the window has a target to render the layout in. A url can also be specified in windowOptions in a snapshot, or when launching a snapshot via other methods.

Window Commands

OpenFin enables your Platform API application to work and feel like a native desktop application. That's why Openfin engineers further enhanced this experience by adding commands (with appropriate hotkeys) to help improve user experience.

These commands can be added to the platform object inside of your Platform API manifest.

...
"commands": [
  {
    "command": "stack.nextTab",
    "keys": "Ctrl+T"
  }
]
...

Window Snapshot

Another important property of the manifest is the snapshot. This property defines the structure of your window inside of the Platform. The snapshot needs to contain the window property where we will define the objects that go inside of it like views, and you can even define the structure of the grid by the layout property each window has. One cool feature about windows is that they can be created and destroyed by the end user, or developer, at any time.


{
  ...
    "snapshot": {
       "windows": [
            {
                "defaultWidth": 800,
                "defaultHeight": 600,
                "layout": {
                    // the structure of your grid
                }
            }
        ]
    }
  ...
}

Window Layout

This property defines the structure of your window. The layout works on a grid system. When working with the layouts, you have to add the content property inside of the layouts property. This content property contains an inner property called type. The values inside of the type value are the following:

row
column
stack
component

In the following code snippet, you can see how I'm using the the content property with the value stack as my type value. Another thing to notice is that there's content inside of other content. The Platform API allows us to have nested content to have the ability to give our window the structure we want.

...
"layout": {
  "content": [
    {
      "type": "stack",
      "content": [
        {
          "type": "component"
        }
      ]
    }
  ]
}
...

View ComponentState

Finally, another property that is worth mentioning is the componentState. This property gives us the option to provide more information about our view. Let's take a look at the following example.

...
"componentState": {
     "name": "example_labs_view",
     "url": "https://www.thisdot.co/"
 }
 ...

This view will render the website of https://www.thisdot.co inside of the view.

Take a look to this complete example:

{
  "snapshot": {
    "windows": [
      {
        "defaultWidth": 600,
        "defaultHeight": 600,
        "layout": {
          "content": [
            {
              "type": "stack",
              "content": [
                {
                  "type": "component",
                  "componentName": "view",
                  "componentState": {
                    "name": "component_A1",
                    "processAffinity": "ps_1",
                    "url": "https://www.example.com"
                  }
                },
                {
                  "type": "component",
                  "componentName": "view",
                  "componentState": {
                    "name": "component_A2",
                    "url": "https://cdn.openfin.co/embed-web/chart.html"
                  }
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

If you want to learn more about the manifest and the Platform API, take a look at the official resources:

Conclusion

Working with Platform API has so many wonderful benefits. It gives me the opportunity to create more flexible software with consistent design, better user experience, and greater security. The Platform API has helped me deliver products faster, with better quality, without compromising the security of my software. OpenFin is changing the way we interact with financial software. Don’t miss your chance to use it!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Pato Vargas
Google Developer Expert on Angular and Web Technologies, Google Women Techmaker Ambassador, Auth0 Ambassador, Media Developer Expert at Cloudinary, Platzi Master Coach, and SpringBoard mentor.
@devpato @devpato

How to add Notifications to your PWA

Have you ever wondered how to add those annoying (but useful) notifications to your progressive web app? Well in this tutorial, I'm going to show you how! What are we building? Live Demo https://pwa-notification-td.firebaseapp.com/ Before We Start We will make use of the Notification API Notification API: The Notification interface of the Notifications API is used to configure and display desktop notifications to the user. These notifications' appearances, and specific functionalities, vary across platforms, but generally provide a way to asynchronously provide information to the user. *Note: *The notification API is not the same as the Push API. Time To Get Your Hands Dirty 1) Clone this repo: https://github.com/devpato/pwa-notifications 2) You will see 3 folders. The ones that matter are the START and the FINAL folder. In the FINAL folder, you can see the final code, but for the purpose of this tutorial, and for you to learn, just focus on the START folder. 3) Navigate to the main.js file inside of the scripts folder 4) add the following code ` The notificationButton is the button that will trigger the notification in our app. If you go to the index.html, you will see the button there that I've already created for you. The swRegistration is just a global variable that will store our service worker. 5) Now let's create a function called initializeApp. This function will handle everything that needs to be triggered when the app first loads. ` To learn more about the PushManger, visit : https://developer.mozilla.org/en-US/docs/Web/API/PushManager 6) When the app first loads, we need to call the initializeApp(). function. To accomplish this - add the call before the declartion of the function itself. 7) Now we need to create a new function called initializeUi. This function will look as follows: ` The only purpose of this function is to attach a click event to the notificationButton. So when the user clicks on the button, something will happen. 8) Now inside of the initializeApp() (function we previously created), we invoke the initializeUi();, right after the swRegistration = swReg; expression: ` By doing this, we will initilize the UI once the registration of the service worker has been successful. 9) Time to create a new function called displayNotification. The function will look like this: ` 10) Go back to the initializeUi() inside of the click callback, where it says "Do something here". Replace that line with: ` Your code will look like this: ` 11) Finally, we are going to create a notification function that will contain the information we want to display in our notification. ` 12) Inside of your displayNotification() function, you will see we are calling the notification(), but it's commented out. Simply uncomment it , so the code can be triggered. 13) The final code will look like this: https://github.com/devpato/pwa-notifications/blob/master/final/scripts/main.js 14) Test the notification in your browser. If you want to test it on a real device, you need to deploy it, and make sure that the deployed app gets served using https. You can you use firebase hosting for this. As you might have noticed, we registered a service worker, but we didn't add any code to it becaue it wasn't necessary. In the the next tutorial, we will actually be doing more with the service worker. In that tutorial, I will show you how to send push notifications from the server using Firebase Cloud Messaging. So, wait a bit and we'll explore much more about Service Worker features ;)...

Jan 21, 2020

3 mins

JavaScript

Understanding Sourcemaps: From Development to Production

What Are Sourcemaps? Modern web development involves transforming your source code before deploying it. We minify JavaScript to reduce file sizes, bundle multiple files together, transpile TypeScript to JavaScript, and convert modern syntax into browser-compatible code. These optimizations are essential for performance, but they create a significant problem: the code running in production does not look like the original code you wrote. Here's a simple example. Your original code might look like this: ` After minification, it becomes something like this: ` Now imagine trying to debug an error in that minified code. Which line threw the exception? What was the value of variable d? This is where sourcemaps come in. A sourcemap is a JSON file that contains a mapping between your transformed code and your original source files. When you open browser DevTools, the browser reads these mappings and reconstructs your original code, allowing you to debug with variable names, comments, and proper formatting intact. How Sourcemaps Work When you build your application with tools like Webpack, Vite, or Rollup, they can generate sourcemap files alongside your production bundles. A minified file references its sourcemap using a special comment at the end: ` The sourcemap file itself contains a JSON structure with several key fields: ` The mappings field uses an encoding format called VLQ (Variable Length Quantity) to map each position in the minified code back to its original location. The browser's DevTools use this information to show you the original code while you're debugging. Types of Sourcemaps Build tools support several variations of sourcemaps, each with different trade-offs: Inline sourcemaps: The entire mapping is embedded directly in your JavaScript file as a base64 encoded data URL. This increases file size significantly but simplifies deployment during development. ` External sourcemaps: A separate .map file that's referenced by the JavaScript bundle. This is the most common approach, as it keeps your production bundles lean since sourcemaps are only downloaded when DevTools is open. Hidden sourcemaps: External sourcemap files without any reference in the JavaScript bundle. These are useful when you want sourcemaps available for error tracking services like Sentry, but don't want to expose them to end users. Why Sourcemaps During development, sourcemaps are absolutely critical. They will help avoid having to guess where errors occur, making debugging much easier. Most modern build tools enable sourcemaps by default in development mode. Sourcemaps in Production Should you ship sourcemaps to production? It depends. While security by making your code more difficult to read is not real security, there's a legitimate argument that exposing your source code makes it easier for attackers to understand your application's internals. Sourcemaps can reveal internal API endpoints and routing logic, business logic, and algorithmic implementations, code comments that might contain developer notes or TODO items. Anyone with basic developer tools can reconstruct your entire codebase when sourcemaps are publicly accessible. While the Apple leak contained no credentials or secrets, it did expose their component architecture and implementation patterns. Additionally, code comments can inadvertently contain internal URLs, developer names, or company-specific information that could potentially be exploited by attackers. But that’s not all of it. On the other hand, services like Sentry can provide much more actionable error reports when they have access to sourcemaps. So you can understand exactly where errors happened. If a customer reports an issue, being able to see the actual error with proper context makes diagnosis significantly faster. If your security depends on keeping your frontend code secret, you have bigger problems. Any determined attacker can reverse engineer minified JavaScript. It just takes more time. Sourcemaps are only downloaded when DevTools is open, so shipping them to production doesn't affect load times or performance for end users. How to manage sourcemaps in production You don't have to choose between no sourcemaps and publicly accessible ones. For example, you can restrict access to sourcemaps with server configuration. You can make .map accessible from specific IP addresses. Additionally, tools like Sentry allow you to upload sourcemaps during your build process without making them publicly accessible. Then configure your build to generate sourcemaps without the reference comment, or use hidden sourcemaps. Sentry gets the mapping information it needs, but end users can't access the files. Learning from Apple's Incident Apple's sourcemap incident is a valuable reminder that even the largest tech companies can make deployment oversights. But it also highlights something important: the presence of sourcemaps wasn't actually a security vulnerability. This can be achieved by following good security practices. Never include sensitive data in client code. Developers got an interesting look at how Apple structures its Svelte codebase. The lesson is that you must be intentional about your deployment configuration. If you're going to include sourcemaps in production, make that decision deliberately after considering the trade-offs. And if you decide against using public sourcemaps, verify that your build process actually removes them. In this case, the public repo was quickly removed after Apple filed a DMCA takedown. (https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md) Making the Right Choice So what should you do with sourcemaps in your projects? For development: Always enable them. Use fast options, such as eval-source-map in Webpack or the default configuration in Vite. The debugging benefits far outweigh any downsides. For production: Consider your specific situation. But most importantly, make sure your sourcemaps don't accidentally expose secrets. Review your build output, check for hardcoded credentials, and ensure sensitive configurations stay on the backend where they belong. Conclusion Sourcemaps are powerful development tools that bridge the gap between the optimized code your users download and the readable code you write. They're essential for debugging and make error tracking more effective. The question of whether to include them in production doesn't have a unique answer. Whatever you decide, make it a deliberate choice. Review your build configuration. Verify that sourcemaps are handled the way you expect. And remember that proper frontend security doesn't come from hiding your code. Useful Resources * Source map specification - https://tc39.es/ecma426/ * What are sourcemaps - https://web.dev/articles/source-maps * VLQ implementation - https://github.com/Rich-Harris/vlq * Sentry sourcemaps - https://docs.sentry.io/platforms/javascript/sourcemaps/ * Apple DMCA takedown - https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md...

Nov 21, 2025

5 mins