 Hello, and welcome to Powering Micro-UIs with FTC3. I'm Nick Colba, I am co-chair of the FTC3 project at FinNOS and the Global Head of Platform at Genesis. First of all, I want to thank FinNOS and the Linux Foundation for all their amazing work in organizing and hosting OSSF. And in general, for supporting open source development and finance, it's been an incredible long journey with FinNOS for me personally. And they're an amazing group of people. And it's just terrific and humbling to work with them over the years. A little bit about Genesis. Genesis is the only financial markets native low-code application platform or LCAP. We have a library that provides ready-to-build building blocks that address complex financial workflows. Our platform enables us to build highly performance-scalable and secure solutions and to do this much faster than if you're building from scratch. So many of you probably are very familiar with FTC3 already. But I do think it would be good to give a quick tour and background onto the history and purpose of FTC3. So FTC3 itself is a standard for application interoperability and finance. It covers three main areas, app directory or describing the metadata for catalog of applications that can interoperate, context data and contents, which is a taxonomy of the verbs and nouns describing interactivity between applications. And then finally, the API, which is a standard for the interface between applications and platforms or containers that provide the interoperability to them. So FTC3 itself started way back in October of 2017, so over three years ago. We started at OpenFin with a slide deck and about 12 technologists from across the industry. We got people together and started this group. We broke up into four working groups at the time and built a lot of momentum. There were roughly 40 community firms involved with the creation and the feedback phase of the initial standards. And those standards themselves were released in March of 2019. In the meantime, FTC3 had been contributed into FinNOS and we launched fdc3.finnos.org and created a lot of tooling around supporting the standard. And in this year, in March, we had our 1.1 release, which was a really major improvement to the standard. And we've also seen a lot of production implementations go into the wild over the past year or more, some notables including FACSET, JPMorgan, obviously OpenFin, Glue42, and Koseik Finsambol. And there are many, many more. And finally this year, we've been focused on the 1.2 release, which I'm going to touch on a little bit. And we're hoping to put the 1.2 FTC3 release out in Q1 of next year. So what was the motivation behind FTC3? So let's take a little bit of a look at what the world looked like before FTC3. So apps get built, as they always do. And you have different apps coming from different development teams. And when they want to interoperate, often developer A will talk to developer B and they may create some informal bilateral protocols or APIs. As this matures, they may create a more specific proprietary API that they can go through so developers don't have to send emails back and forth or get on the phone to figure out how to make things work. Then as this scales and we get more applications and more developers into the mix, this starts to get really quite messy as developers need to track different APIs that may be formal or informal across different applications and try to make everything work. So with FTC3, everybody just speaks FTC3. So each developer only needs to speak to this one API. And as more applications are dropped into an environment, they'll simply, because they're talking FTC3, be able to interoperate with each other. FTC3 also works across a number of different technologies, including, as mentioned before, OpenFIN, Finsamble, V42, but also any electron-based container also runs in WPF. There's implementations in Java as well. And there's even an implementation structing in Chrome, which you'll actually see a little bit about later. So let's talk about microUIs. So microUIs kind of a, it's become a bit of a buzzword. But what these are really about is creating small self-contained front ends that can be put together kind of like LEGO bricks. So microservices have been hugely successful in enabling platforms to scale on the back-end side of things. But until recently, most microservice platforms have been fronted by what are monolithic UIs. So here we have all of your nicely decoupled microservices going into a single monolithic application. So when we create an analogous set of services using microUIs, you can scale the front end in a kind of analogous way to microservices on the back-end. So design systems, which have been very popular in application development, are only concerned with visual language. But microUIs create a functional workflow language. They create building blocks that combine both front-end experience and back-end functionality and data. So let's look at some of the major advantages of microUIs in application development. So big one is reusability. MicroUIs make it very easy to stamp out front ends with minor variants. Flexibility is also critical. And you can configure microUIs very easily using them as building blocks to make very different shapes. And finally, personalization, the componentized UI makes it easy for end users to configure the front end and to meet their specific needs. It also makes it easier for applications to fit into an end user's preferred workflow through embeddable components. There are examples of embeddable components everywhere from Google Maps widgets to sign in with X SSO buttons, embedding symphony or other chats into applications or embedding YouTube videos. These are all examples of self-contained microUIs that can be injected into a workflow. So here's an example of microUIs that we've built using the Genesis platform. Actually, in this particular case, these applications are running in OpenFIN and using it as a container for the presentation layer. And this allows each UI to run as its own app but to be composable with the other applications and these kinds of tabbed or split layouts. So but the micro UI approach isn't without its challenges. When we give up the control of a monolithic application front end, there are a number of new problems that emerge. The first one we can think about is component inflation. So in this case, if components aren't shareable, the reuse of those components can create kind of bloat noise and poor user experience. This means that because these components can proliferate so easily, we just end up with a lot of access noise within our user interface. So common services and capabilities and information can just end up being repeated across lots of places. A really simple example of this phenomena is the proliferation of tabs. We experienced in browsers. Now consider that versus repurposing of apps when we go across contexts in mobile where we don't end up with 20 different instances of the Google Maps app opening up every time we open a new map. Well, if you're running in a browser, that can very well happen. Another issue is discoverability. When workflows are divided up into many different independent components, how is an end user going to discover relevant content and functions at the right time? So you make everything into a LEGO brick, but pretty soon your pile starts to look like this. And it becomes very hard, especially the more generic you get to find the right things. Finally, once you have everything as a micro UI, where does your workflow logic live? When you have things as monoliths, you can have controllers that orchestrate across your monolith quite easily. But when things are decoupled, doing that orchestration becomes trickier, and you need a mechanism that components can rely on to communicate. So in summary, micro UI strategies are good at disassembling monolithic applications into more flexible and personalized dashboards. But creating multi-step workflows, sharing common components, enabling end user discovery, and integrating second and third party components is quite a bit more complicated. So FTC3 helps us solve these problems. Those areas of FTC3 we talked about before bring huge amounts of value when we're working with micro UIs to build interactive user workflows. So app directory and intents solve for discoverability across applications and across UIs. Context sharing solves for workflow integration across those UIs. And finally, data-driven intents solves for service reuse. So let's look at the first use case of connecting to the app directory. So in this example, we have a grid of instruments running in one application. And when right-clicking on a ticker, FTC3 is going to allow us to easily search an app directory and discover the applications and intents that are relevant to that ticker. You can see here you've now gotten a whole list of applications organized by intents. And let's look at the code that enabled that. You can see it's quite simple to implement this kind of functionality in FTC3. In this case, we're using an API called find intents by context, which we see here. We pass in a context that's going to come to us off of the grid context. And we get back a, this is actually, it's an asynchronous response. We wait. And in fact, this is getting back a data response that we then pass into what actually is a web component that we're using here to render that menu. Interestingly enough, one of the things that we are doing in FTC3 1.2 is making this kind of workflow even easier to implement for an application because you'll be able to pass just a single API to the desktop agent on the FTC3 API, basically the FTC3 API provider. And then they'll be responsible for drawing that menu for you. In this case, the application itself is drawing the menu. So let's go to the use case of sharing context with using channels in FTC3. So once we've discovered our applications, we want to be able to keep them synchronized through sharing context. And there's been a lot of work that's gone into, especially FTC3 1.1, to enable rich context sharing using this concept called channels. So in this example here, we're going to see using the FTC3 desktop agent here to select a color channel that I'm going to put this application on. I just put it onto the red channel. And now I'll receive and be able to broadcast context over that channel. And then in this example, we can see that in action in a little more detail and also combined with intents. So I'm going to, again, discover applications by intents for this context. I open up a news application. And now I'm going to put the news application onto the red channel. And I'm going to move that app over to the side so we can see both these in action. And I'm going to have my grid already on the red channel. So as I click through new context, it's going to reload the news with the new context I selected. And you can see how doing this really enables end users to discover functionality and also to build new connections between unrelated apps. This is really OK. So let's look at now taking the channel concept and publishing data with channels. So taking FTC3 channels, we can take that color channel example. But there's also another kind of channel in FTC3 that's called an app channel that essentially allows the creation of what we can think of as private channels for applications. So we can actually adapt that API to allow us to publish data to other applications using those channels. So in this video, you're going to see this is the FTC3 channel manager demo app that I've now created a private channel or app channel called My Channel on both of these apps. So they both have created the same channel so they're synchronized to it. And they are now exchanging context back and forth over that channel. So this could be used to create this kind of private interaction. But it could also be used to broadcast or to publish, let's say, streaming updates for some data over a specific context channel. So there's a very flexible API that allows you to do a number of different things. So this is what that API looks like. So this is some of the code that went into that app. Again, it's not a whole lot of code to implement FTC3. So in this case, when I clicked on the button to create the channel, it's using the FTC3 get or create channel API. And I pass in a name. So this is going to either return that My Channel app channel if it already exists. If it doesn't, it's going to create it and then return it to me. Once I have a channel object, I can now both add a context listener to it. I can also broadcast over it. And in this case, you see the code for me to broadcast. I'm sorry, to add a context listener onto it. And then once I get a context on it, I get to respond to that. So this is great. But there are problems with this kind of pattern using app channels. If we wanted to build a kind of client provider relationship where an app maybe is streaming data out to a number of subscriber apps. One, there's no service discovery here for app channels. App channels, because of number two, because they rely on security through obscurity, there's no mechanism for publishing the identity of those channels or built into FTC3 or to sort of discover that through another mechanism, like we have, for example, for intents where I can say, I want to view a chart and I can get a list provided by the desktop agent of applications that support that functionality. This also risks fragmentation of standards. So if we create lots of kind of private channels to do various functionalities across our applications, chances are it's going to be very hard to upstream anything we're doing there back into the standard. It's not really helping advance a common language. It's really creating more opportunity for just private conversations to happen. And then finally, it really creates a lot of need for handshakes and lifecycle management. So the example we just looked at is very simple. We're just broadcasting context back and forth. But in a real example, if I wanted to share a data feed to something, I need to know first of all, I need to be able to initiate the back and forth between two applications. And then I would need to know when an application goes away, if it's when it's loaded, et cetera. So there's really no space in that API for that kind of functionality. So this leads us to data-driven intents, which is a proposal that actually we've discussed for quite some time on and off within the FTC3 community. And we're now been working on a formal PR around this for the 1.2 standard. So what is the proposal? At the heart of the idea of data-driven intents is that you can have an intent that's going to return data or initiate a data stream as opposed to the intents that have existed in FTC3 so far, which have been largely kind of fire and forget. You say, I want to view a chart. You raise that, send a context over to some application that gets resolved to, context goes over, and you never hear from that app again. So that has its place, but it's also fairly limited. So at the heart of the proposal for data-driven intents is really the concept of the app instance that we can get a reference to an app instance as part of a resolution of an intent or an exchange of context data and that I can, as an application, use that app instance identifier to then either listen to context events from the app instance or to broadcast additional context to it. So again, the app instance will provide a reference to a specific app instance, not the app as a kind of class. It can be created from a source identifier. Now, a source identifier was something that existed in FTC310 as part of the intent resolution object, so after you've raised an intent, it gets resolved and routed to some other application. In the resolution you get back in the API, you will get a source, but this has been fairly vague, what it is. With this update to the spec, we're saying that a source identifier is a identifier token I can use to return back to the desktop agent, and then it will give me a reference to that specific application instance based on that token. And that will be returned not just from intent resolution, but also from context messages. So if I get context broadcast to me, there will be a source token associated with that message that I can then use if I receive context from another application to get a reference back to the application that sent me that context. The app instance object itself will support both broadcast and on-context listener methods, as well as lifecycle events, so you'll be able to listen to the status of that instance and know when it's gone away and when it's loaded. So let's look at the draft type for app instance for a second to illustrate the previous points. Again, this is a draft. This is essentially pre-PR, meaning that this code exists on my fork, to be honest today, but there will be a PR coming soon. You can see that we have the standard interfaces for app context listener. You can listen both. You can add a listener both just adding a function or using a context type filter. You can broadcast. And then there's this on status change, which supports a handler that can be passed into it, and there is a status property that can be ready, loading, or unregistered. So let's go to a demo. We can see what this looks like. This is built using some tooling from the Genesis platform and then using the FTC3 desktop agent project to model out the functionality that's being proposed. So in this case, I've got two client applications on the left. I'm just going to pause that for a second. And three provider applications on the right. The provider applications are providing, well, it's all mock data, but FX pricing on currency pairs from a different liquidity provider. And then the client applications on the left are going to create raise intents for a specific currency pair, actually send over an instrument context for that to get pricing for that currency pair. And then what's going to happen is that since there are multiple providers of pricing running in this desktop agent instance, the end user will get prompted for which provider they want to get the pricing from. So there is our intent resolver. We've chosen BNP, and we start getting pricing back. And you'll see that also pricing should update. In this case, we've now chosen Citi for the other currency pair. And we can actually switch to a different provider. We're going to switch to DB here. And you can see the pricing gets updated. So that is data-driven intents going across FTC3. Again, we have two different clients that are raising intents to request pricing. They're presented with options of different registered providers for that from different liquidity sources. And once a provider is chosen by the end user, that application now listens to context updates from the provider. The provider is sending those updates specifically to that client. So they are forming a one-to-one relationship with that handshake. So let's look a little bit at what that code looks like. So this is the code for within the data provider. They are handling the intent. So at the top here, you can see that we're using FTC3 Add Intent Listener. We've created a, in this case, just a Genesis name-spaced intent name that's just a working title, find FX price. And we're passing in a handler, which is this handle price intent function. Within that, what's interesting is we have this, we get from the intent, the source is handed, is passed into us from the intent handler. So this is new. And from this source, we are resolving that into an app instance. And then we do some things to get data. And we also do some things to create, to push the last value cache when the subscriptions first made. So as a service provider, when we want to, when we get our data update from the back end, we now are going to, so we've basically taken our instances and we've created a map of them called subscribers. And then when we get an update for a specific currency pair, we are now going to push that to any subscribers for the currency pair. Obviously, there's a bunch of details that are fudged here for the demo, but you can see the structure of how this would work. When we get our subscriber, we're just going to, we've basically put the instances into the map that we resolved originally when the handshake was made. And now we're just going to broadcast the new context back to that instance. Once again, I think it's important to point out that we're not doing a broadcast over a channel that anything could listen to. We're doing a broadcast specifically to that instance. So it's only, it's a, it's a direct message to that instance, which allows kind of the space for a desktop agent or for an app to provide real privacy around the data and how it's going to be routed or if a application instance is even going to be allowed to connect to the provider. So this is what the code for actually raising the data intent looks like for a client. And again, this should look pretty familiar. We're calling FTC 3 raise intent and get a result. What's new here is that once we get the result, we are using the source property of the result, which has always been there. It's just that we haven't really been able to do very much with it. And we are getting an app instance. And then once we get the app instance, we're doing some things to resubscribe to things that we only are listening to one feed at a time. And then here we're going to add a context listener on that instance itself for the update FX price context. And again, we're listening just to the source. It's a direct connection. And then we're using that to update our UI. So what's next with all this? LCAPs are really accelerating the trend towards greater reusability and composability of back ends and front ends. And that's unlocking enormous value. That's because we're delivering high quality applications at an even faster pace. FTC 3 fits into this whole story because it provides a wealth of tools that make user experience and componentize workflows even more personal, intuitive and effective. Data-driven intents, I believe promises to be a really critical addition to this toolkit. So contribute to FTC 3. There are a lot of different ways to get involved. First step, go to the GitHub site. GitHub, Phinos, FTC 3. There's a huge amount of information there. And of course, you can see all the code. You want to see the code for the desktop agent, which was used in all these demos and use the code, contribute to the code. And also a Phinos open source project. This allows you to run a Chrome extension that fully implements FTC 3. It goes against a app directory that is public. And you can actually swap it out to your own app directory. Once again, all the codes open source. So feel free to fork to make PRs and contribute. It's a really great way to get FTC 3 up and running fast. And also to be able to model quickly new ideas in FTC 3 like this one. Subscribe to the meetings calendar. So FTC 3 holds a standard working group meeting every four weeks. You can find the information on that there. If you are interested in helping just contributing from a project management aspect or product management aspect, there's also our project management committee or PMC that meets every two weeks. And then finally, you can always join the general lists, send emails there for information. And you can always reach out directly to me or other members of the FTC 3 group if you have any questions at all or just unsure of where to get involved first. But there's a lot going on and we're a friendly group. So thank you very much for your time. And I hope to see you on the in the open source world very soon.