 My name is Baladat. I am a principal engineer at Intuit. And I'm going to talk about JavaScript plug-in architecture for single-page applications. Before I start, how many of you have a situation where you have to integrate your application with a third-party application in browser? OK. So good number of you. It's good. You guys can share your experiences also. I would love to hear that. And feel free to ask me questions anytime in between. So I work on an application called as QuickBooks Online. It is for small business management. So if you have a small business, you have to generate invoices to your clients. You go and buy something from your vendors. You generate purchase orders. At the end, you want to see your profit and loss account, balance sheets. And you also want to file taxes to the government. All that is handled by this application. It has 175 K log JavaScript code. It's pretty big. And it's increasing. So as we add more and more functionality, it's getting bigger and bigger. It's a single-page application. It has very active uses. So it's not like a website where people come once in a day and go back. It's an application that businesses use throughout the day. And they are almost always into that application. It can be accessed from multiple devices. It has 1 million users, as of now. It is accessed across the world. So it's global. We have launched it formally in five countries, but it is accessed by many more countries. And it's a little different from other applications where going global basically means you change strings and you take care of localization. Here, it means that you take care of the laws of the land, the country that you go in. They demand very different treatment of accounting and very different treatment of taxes. So we do all that. So just to tell you that this is a very complex piece of functionality. We deal with compliance. So anything wrong we do, government or the tax departments would run after businesses. So for all this, we can't build a whole of the application ourselves. We have to rely on third parties who build part of it and we integrate with them. We could build a good amount of functionality for US, but if we have to go global into different countries, we can't build everything of it. So that's where we need some capability for third party applications to integrate into our application. And even internally, we have multiple teams. We have multiple divisions that build different parts of the application. There is a team which takes care of accounting. There is a team which takes care of payroll and payments, et cetera. All those things have to come together and we need modularity there. So this is the motivation. This is the problem, the solution to which I'm going to explain now. So it's all about creating an ecosystem. You know, you can't build everything. So you better have a place for everybody and a way for everybody to integrate their stuff into your application. What are some of the approaches at a very high level? There is, you can have a service-based integration where one part of your app has a separate endpoint. People go to that place. And only through services, the data is exchanged between the two applications. The other approach is you have browser-based integration where people go to only one app. People only get to see. Your customers only get to see one app. And everything is inside that. So this is the second approach. And this is what we are going to talk today about. In that, you know, there are two approaches. One is an iframe-based approach where you get the content of other application and integrate into your application using iframes. And another is a very lightweight way where you can get JavaScript modules directly into the application and let them behave as part of the application. So what do we do? We talked about plug-in. What is a plug-in? A software component that adds a specific feature to an existing application. It's a very simple and generic definition. And you know, we have a lot of examples in industry about plug-ins. People build a core application that does one thing well, and then they let plug-ins to come in and enhance it and make it really rich. The same approach we have done. Why would you do that? It's basically about enabling developers outside the core product to add features. It's about making it easy for those features to be added. It's about keeping the core very small. And it's about enabling independent releases. So let me tell you what I mean by independent releases. If you have 10 teams building a good piece of functionality in your application, and all of that has to come together as one application, as one release cycle, you are bound to get very slow. It is a good idea for all these 10 teams to build and release separately, and all of that to come together to the user as one application. So release independence is a very important criteria for you to be agile, even when you are building such a large-scale big application. So question for you. Which one of these do you think has a plug-in? All of them. Which one of these do you think has a third-party plug-in? OK. Cool. We'll come back to this. But just keep in mind this picture as we talk. So I tried to look for some examples of what integration are there. And there is this site, which has very bad integration, I would say. It gets worse. Ads is OK. But when you search for hotels, you are suddenly taken to a very different site. And both of these are from railway. So I think there are some lessons to learn before you even start thinking about integration. Let me tell you a little bit about this. So first thing, if you are integrating into a third-party application, you have to take care of identity. So identity has to be shared. That means that I should not be asked to log in again into that third-party application. Design an interaction. You have to make sure that the plug-in and the main application, they look and feel the same. They have same colors, fonts, et cetera. So what do we do at Intuit? We have actually given our style guide and a style language and some set of tools for third-party plug-in developers to build plug-ins and integrate into the application. Second piece is consistency. There are some certain paradigms that we have built. I'll talk about them like trousers, global creates, knabs, and all that, which your third-party plug-in should also honor for a user to have a seamless experience. Plug-in should be first-class citizens. So a lot of you said that everything is a plug-in. We try to make internally every feature as a plug-in. And that's what gives plug-in a first-class citizenship. So it's not that you create a certain piece of API and give it to your third-party developers, and that API is fairly restrictive and only meant for third-party. But you actually eat your own dog food, and hence you make your API very rich. You have to take care of roots. So people would bookmark different states of the application at different places. Your third-party plug-in might be actually saving data. It might be having different states. It might be storing preferences of the user. All that you have to take care of while you are building so that you give a seamless experience. If somebody goes to a plug-in and navigates out, you better save half-filled form data somewhere and retrieve it back when needed. So this is a basic iframe plug-in. Most of it, there is nothing but hello world, and that's the content area in which it shows up. And what you need to create a basic plug-in is nothing but just give an ID, give a location, and give a source path. This index.html will be loaded and placed at the point. Now let me tell you a little bit about access points and app routes. So on the left side, we have what we call a left nav. And on the top, when you saw that fly out coming, it's called global create. And on the right side, there is a settings fly out. All these are part of shell, what we call a shell. Shell is something that always exists, and it's where plug-ins come in, hook themselves, and are accessible from shell. All these places have something called as access points. So we have got, let's say, in the settings, we have QuickBooks lab written there. We have an access point there. We would have an access point on the left nav, and we would have access point right in the content frame itself. And you have app routes also. So actually, you can do two things. You can go and say that, hey, my plug-in, I need to be shown from this access point, or I want to even capture the route. And both of these clubs together are called as attach points. So as a plug-in, you basically write attach points and you get hooked into the application. So let me show you a quick demo of a simple, very simple plug-in. This is QuickBooks application, and OK. So this is where I am running my node server. This is a small plug-in that I am running from where it's on my local host, and the plug-in will be delivered from here. So what does plug-in do? It shows up inside the setting. This is cool plug-in. It also shows up here. And it actually takes on the route that is represented by this menu item. So let me show you this. This whole thing was taken over by the plug-in. And what does this plug-in do? It basically demonstrates few things. So let me click on this show page message. Once you do that, this small toast that comes, it is actually coming from the main application. Every plug-in will not have their own toast coming. And you know, very different kind of experience. So it basically has to request the main application to get to show the toast. Even the dialog box is shown by main app. You can actually request main app to show a video. OK, maybe the network is slow. So a video can be shown inside the application. Now let me show you that this is really working. So what I will do is I told you about the link that appeared there. I'll change the name, call it jsfoolplugin. And I will reload this application. OK, so you see the text there that has changed. This was a small demo. I'll take you through the details of it. I'll refer to the code here as I discuss more. So what just happened? First thing is the plug-in has to be loaded. Remember that the plug-in is per user. And it is per even locale. So some plug-ins are only available in India and not available for US customers and all that. So there is a list of plug-ins that are applicable to the current user. First thing plug-in loader does, it goes and fetches the configuration from the server. It merges that configuration from a local storage server. So this second piece is for developers. As a developer, I just enabled a plug-in. This plug-in is not available to all customers. It's just for my testing, my usage. All that information is stored right in my local storage in my browser. And the app basically makes use of it and shows that plug-in also, as if it was available to everybody. And the main app router, whenever that particular route that you're acquired, that route is triggered. It basically passes the control to iframe controller, which executes your application. Now I talked about attach points. So I said it is where your application hooks on. And access point is one of those attach points. Route is another attach point. And we actually changed the text of this just now. This is how you override the app route. So you say that, hey, customers or employees, et cetera, all these routes are override and you get control. Your application gets control whenever these routes are triggered. Now there is an important piece to this, which is how does the parent application communicate with the child application, which is basically a plug-in, when the plug-in is running inside iframe. We know that same origin policy and iframe controls prohibit easy communication between these two applications. For that, we use a library called as EZXTM. It makes cross-domain communication easy. What does it do? It basically allows you to create certain channels between two frames and use JSRPC to communicate between them. So you can basically, the child application can call well-published interface of QBO core application and get things done. So for example, when we called, when we said show message, show page message, we actually called into core application and said, show this message. So all this is possible using EZXTM. And it's completely JavaScript library. It depends, depending on the browser, it uses the right protocol. Most of the time it is post-message. Now, what happens? Let's, so the first thing, if you look at this application, it basically has just index.html. And it starts executing here. This basically says that whenever the plug-in starts, the core application would actually fire a post-message with some set of data, initial data, that this plug-in has to hold on to. And from there on, the communication channel is established. What does it do? It basically takes this piece of data that has come as a, into this message and hooks it into its own DOM. Now, from there on, there is a object called as QBO-XDM that is available to the client application. And QBO-XDM is a EZXTM-rapped object containing QBO interfaces. And plug-in can use this object whenever it wants. So, this is about getting the initial QBO-XDM object. If you want to basically hook on to the ready message, so whenever your plug-in is loaded, you want to have a ready message and you want to hook on to that time, you use this QBO-XDM ready object and this will get called at the right moment. So, this is how you basically call the parent for showing a page message. This is how you call parent for showing simple local dialogue and you can actually ask you to show a video too. It is many times, it is not just the menu item, but you would like your plug-in to show up inside a particular form also. And that's where, you know, this comes in. So, what do you do after you've created a plug-in? We have a feature inside our application called as QuickBooks Customer Labs. It's a place where all the applications are published and customers also get to see that and they basically can choose applications from here. They can switch it on and use them. So, this is where your plug-in will show up. This is one plug-in that my team worked on and this is part, so this is just to show you that, you know, many times some of the core features are plug-ins that we expose as in QuickBooks Lab and let customers opt-in. It's a good way to do beta testing. Okay, so, what I'm, before I wrap, let me quickly take you through the code once again. So, what have we done? We basically defined a configuration that the plug-in manager inside QBO understands and most important part is this source path. Where we specify the HTML file that will be loaded by the plug-in manager, whenever all these things are triggered. So, whenever this route is triggered, that index.html will be loaded. When the links inside settings is triggered, that same thing would happen. When you basically, let's say, want to show, so let me tell you a little bit about browser, what it is. When you show up forms here, part of, good part of area is taken by this left nav and, you know, all these elements outside. Sometimes, we want the whole screen to be available to the form, like this. So, this is what we call as trouser. It basically comes down and it takes the whole screen. Now, what if the plug-in wants to access this? Plug-in has a way to do that. You know, it can also show up inside a trouser. It basically requests the parent window to show up a trouser and render the plug-in inside it. So, this is how you show inside the trouser and, you know, you can also show inside form. So, we actually saw the sales tax thing. So, when we clicked on invoice, we saw this. This is basically the plug-in showing up. So, this is how you define your plug-in and this is how you write the code. You get, you can make controls. You can make calls to QBO to do a lot of stuff. You can make data calls to get data and you can integrate into different parts of the application. So, to conclude, you know, this is a way to build plug-in mechanism for your apps. And it's to encourage you to build such mechanisms into your app because you will realize at some point that you would like third-party applications to also plug-in into your application. It allows others to build stuff into your app. Make sure that you eat your own dog food because only that can ensure that you have a rich and meaningful API available. Always try to allow a developer into your ecosystem without having to talk to you. There is one principle that we try to adhere to and into it. What's the future? What are we doing after this? This was basically V1. We have been working on V2 of this plug-in. So, we are thinking of, you know, AMD loading of plug-ins so that plug-ins can live right inside the parent application and to make sure that these plug-ins are isolated from each other. So, you know, we have a notion of sandbox where it is in a container for plug-ins and it provides, plug-ins use that sandbox to access different services. You know, for example, passing event, there is an event bus, they can pass event back and forth. They can access models, data, et cetera. And they have fair isolation, so they don't have to depend on presence or absence of any other plug-in. If you need more details on the future, feel free to come to our booth and talk to the engineers there and we can explain you in detail. These are some of the links. QuickBooks, you can actually get a free QuickBooks trial if you go to google.com and say QuickBooks online test drive. developer.intuit.com is our third party developer portal where you can get a lot of information and a lot of tools. The code that I showed you is here. It's called starter plug-in. This is all about what I wanted to talk. Thank you. If you have any questions, I'd be happy to take. Hi, so one of the major issues when you open your application to third party developers is security. So how do you guys handle that? So, good question. First thing is, you know, you have to, you cannot open it to anybody. You have to have a process to verify and vet out an application. So somebody has to submit and there has to be a review process. People can't build in wrong stuff, viruses, or, you know, bad code into it, crash your application, or steal data, et cetera. So you have to have a review process. That's first thing. Second thing is, you have to, you get to limit the amount of things that people can do. Clients are generally always assumed to be in untrusted zone. So your services basically take care of dealing with any calls that are coming your way. So you have to treat this third party plugin also with the same untrust, distrust, that you treat any call coming from internet. So that's basically making sure that nothing bad happens to your customers. On the other side is that you have to make it easy for your customers to use it. So I talked about shared identity where you have to allow easy ID federation. Other third party applications do not have to use your ID systems. They can have their own ID systems. They maintain their own identity, but there is some kind of federation and some kind of close control around that ID federation. Now, it's also true that, you know, when you have, you ultimately want to give good features and good experience to your end user. So sometimes you cannot be too paranoid about data. I mean, for example, you know, you might say that somebody can take data and steal it away, but it's a trade off between how much forceful, how much flexible and powerful you want those third party applications to be to deliver a rich and good experience. So it's a trade off and, you know, it's, there has to be some manual process also. So any more questions? Question? No. So we'll be breaking for tea, I guess. So see you guys in half an hour. All right, thank you.