How to use the Bubble App Connector – ratio.dev

Dennis H. Lewis shows how to use the Bubble App Connector to split functionality between apps, reducing plugin bloat. A Web3 example: a DESO blockchain plugin added 1.5 megabytes per page load, so they moved complex transactions to a separate server app connected via the Bubble App Connector. Setup requires capturing the server app ID, generating API tokens, and registering the server app in the client with matching credentials.
Questions this video answers
About 1.5 megabytes of data per page load.
Private key, Client id, Client secret.
The Bubble application ID (from the app URL) and an API token generated under Settings → API (server).
API key or OAuth.
Chapters
Hi, I'm Dennis Lewis and in this video I want to show you how to use the bubble app connector. What the heck is the bubble app Connector, you might be asking? First of all, it is a unique, pretty much neglected method for making two bubble applications or more work together, almost as if they were one single application. To be honest, I'm not really even sure that Bubble is still promoting the bubble app connector very much. They just, it's just sitting there. But if you need this functionality and you put it to use, it can be a real powerhouse and it can really help you. So unlike the sub apps or the parent child apps that require you to have an enterprise account with Bubble, which is obviously expensive, the bubble app connector works with any bubble application, regardless of the plan that you're on. So that's an important thing to take into account. So I think the first thing I want to do is just to share with you guys a real world case, real world use case that has been proven to me to be truly successful, and that is with our Web3 blogging platform, Circles, and how we connected it to the Web3 backend that we built using the bubble app connector. So let me tell you a story. Okay? First of all, we built an awesome bubble plugin for connecting the bubble with the deso blockchain. We poured months of development into building this plugin and we added in all of the transactions that a bubble application builder might want or need if they wanted to really exploit the diesel blockchain. And man, we poured everything, the kitchen sink into that plugin and it. And we got it where it really worked well. So that was great. And guess what else happened? It was humongous. And this led us to discovering that there is this sort of unspoken, ugly reality about bubble plugins that most people don't realize. And this is what happens whenever you install a plugin into your bubble application. If it has API calls, if it has structures that it's built inside, all of that overhead is going to be loaded onto every page load of your application, because that's just how bubble works. So it's the definitions of that plugin get loaded on every, every page load and this will slow your application down. And this is the key source of what I like to call bubble plugin blunt, because it's one of my pet peeves. Because.
Now if it's just a little visual plugin that does something on the screen, it doesn't matter. It won't hurt anything, it won't slow anything down. But more complicated plugins that have Lots of logic and that do a lot of stuff. They will provoke this load in your application. And.
That'S the bad news that we discovered with our DESO blockchain plugin was that it was loading about 1.5 megabytes of data on every page load for the application. And no wonder, at that point we were getting comments from our users saying oh, we really love zirpals, but it's slow. And they were right.
Then we had a sit down and talk to Jesus moment. Was it over? Was that the end of the road? That was one question we asked. Do we have to just throw out all of these months of development building this amazing plugin and start over and do something completely different? I can tell you we're not a humongous corporation. We pay for every one of those development hours was coming out of our pockets. So we take these decisions really seriously. And the only thing I knew is that there had to be a better way. And so that's where the bubble app connector came in and saved the day for us, really. You see, almost all of the functionalities that were bloating our application were back end functionalities. They weren't functions that the user was needing in the client side front end. They were creating transactions, creating NFTs, creating posts and comments and DOW coins and all sorts of things going on in the background. But.
They weren't really essential for the day to day operations of most of what people were doing in circles. They happened behind the scenes. And so what we did was we decided and we built a new plugin. We took our big mammoth plugin and we stripped out everything that wasn't essential for the client side front end and we called that the light plugin and we created that. It is really lightweight, doesn't slow things down. Awesome. And then what we did was we moved and we installed our big plugin into a second bubble application. And this was the server backend server for Diesel. No code that we built. And it is what processes all of the complex logic of all of these transactions.
But that left us with the problem, how do we make these things work together? And that's where the bubble app connector comes right into the game. The beautiful thing is that all of these backend functions are now available and they don't slow anything down. Because bubble doesn't make the same mistake with the when you connect a bubble, another bubble application with the app connector, it doesn't load all of that into the memory of the on every page load. So you get in this architecture, we got all the benefits of all that hard work that we've put in and we were able to drastically reduce our page load speeds by getting rid of a bunch of bloat in the plugins that we had installed. All of this has proven to be an awesome method, not only for offloading complexity, but for increasing user experience and reducing costs. Okay. Because now that we can concentrate all of those transactions in one app that's just working in the background, and it doesn't really have users, so it doesn't really require a big plan, but it's able to process a lot and it communicates seamlessly with all of the applications that we've built using this Web3 integration. And they all talk to this server app. So how does all this work? Let's jump into the bubble builder and let's go see. First of all, you're going to have to answer a few questions before you get started. You're going to have to ask, first of all, which application is going to be the server and which is going to be the client? Okay. And in our case, the server is the dcl, no code application which sits in a background, and the clients are all of the other applications, and there's quite a few now that work using our architecture and utilize our functionality, but they don't have to have all the complexity in their apps. Second question is, do you need to share user credentials across these apps? Does it need to have. Every time a user logs in, do they have to have an account in the server application or not? And we'll talk about that a little later. And then the other thing you need to do to ask yourself, does it need to go both ways? So does your server app need to be able to execute functions in your client apps or in your client app? Because that will require some additional work as well. So the first step is you're going to do is to set up what you need to do in the server app. There's really not that much that you need to do in the server app. All you're really going to need to do is is set up an API key and capture the ID of your bubble application. Those are really the only two things that you're going to need. So you don't have to install any plugins in your server app. Don't need the app connector there. You're just going to, first of all, look at your the URL for your application and you'll be able to find the name of the application. It'll be in the URL. It'll say ID equals in the name. So you'll just need that. And then you're going to go to your Settings tab and you're going to go to API up here at the top and you're going to scroll down and create an API key. Okay? So you're going to go down, there's going to be a. Generate a new API token. You're going to click this for the Client app. This is where we're going to get. You're going to get the client id, you're going to get the Client secret fields, and you're going to get a field called Private key. You're going to need those three tokens. They're just strings of text and store them. And that's all you're going to need to do on your server app. Okay, the next thing you're going to do is we're going to go to the Client app, whereas that's where you've got to do a little bit more work here. I'm going to go into.
Circles. And the first step that you're going to do is you're going to go to your plugins and you're going to install the Bubble app connector. Okay? And here you are going to. Once you've installed the plugin, you'll see a button down below that says add a new Bubble application. You're going to click on that button and you're going to just put in these values that I told you. You're going to have your. The URL for your Bubble application, use the id +bubbleapps IO. That is what you want there. You want to leave this matching version so that it is able to work both with Test and Live and it doesn't mix them up. You're going to put your. You're going to give it a name, so server, whatever it is you're calling it. And then you're going to put in those three fields those three tokens. I told you, the Private key, the Client id and the Client secret. And once you've done that, click on this button called Add an API Call. And that will allow you to connect with any backend workflows that you've created in your server app that you have exposed via the API. You're going to tell it if you're going to use it as an action or as a data call. And then you're going to tell it the type of authentication that you're going to use. And that here can be API key or OAuth. In this case, we're using API key. And with that, now you can call these APIs straight from your any bubble workflow or any expression in your bubble application that it can call any data, anyone that's set up as a data action, and automatically communicate with that server application without anything else. That's all you need. And it will handle all the communication between them seamlessly. And you're pretty much good to go from there on. But there are a few more things I want to talk to you about. I want to talk to you about synchronizing users. So basically, you can set this up so that when you create a new user in your client app, it will automatically create a user in your server app. And that way each user exists on on both applications. Then it will allow you to control each user's access to data in the server database via privacy rules. So it is a powerful function to do this. You'll have to set up what's called an OAuth flow, which is a process that when the user gets created, it will go redirect to the server, create the new user and send it back. And when we first set up the bubble app connector for Zircles, that's what we did. And we just relied on privacy rules for our security. And it worked fine. It was good. But it had some drawbacks. I want to be clear and honest with you here. First of all, it makes your onboarding experience a little more complicated. There's steps in there that the user has to see. Even if it doesn't really require much more than clicking on a button, it still increases the friction there a little bit. That was one of the drawbacks that we saw. And we also realized that.
We were going to have multiple client applications working with this server. And it got tricky when there were different users with the same email on different platforms communicating with the server. And it was an added layer of complexity that we realized we didn't need. And so what we did, we changed our APIs here to API keys and we built in security functions into each of our workflows. So we created a custom event that checks various security parameters that we've set up and protocols. I'm not going to get into the details there for obvious reasons. And we do that on a security check on every API call so that there's no chance of anybody manipulating our server. But that way we can just obviate this whole process and it allows us to have. We could have a hundred different client apps working with our server app, and it wouldn't make any. It wouldn't make it any difficult t for us on the server app. And it also makes it super simple for the client apps. They don't have to do anything in their onboarding, they don't have to change anything to be able to function with our Web3 backend. So that was our decision. But obviously your path is going to depend on your specific needs in the your application. So if you want to use the app connector to execute functions now from the server into the client, what you're going to have to do is you're going to have to repeat the process and you're going to have to install the plugin, the app connector plugin in the server app as well, and then create an API key in the client app. And then that way you can expose those APIs and you could do it both ways. So that is really powerful if you need that functionality. Where I would say to be careful is if you're going to have a scenario like ours where you have multiple client applications, then it's going to get really tricky to figure out how to build workflows that are going to depend on each client because those API calls are going to be separate, they're going to be different. If you need help with this or you want to discuss your specific use case, feel free to reach out to us. Okay, we can, you can leave us questions in the comments below. You can reach out to us on ratio.dev and we can help you implement the app connector in your your scenario, if that's what you need. Because there really isn't a lot of information out there about how to use the Bubble app connector and there aren't a lot of agencies or people I think, with real world experience using it on a pretty consistent basis. That being said, I think that the Bubble app connector is an awesome functionality of Bubble. I think it can really save the day in specific cases that maybe you're bumping your head against the wall trying to figure out how to solve issues like we had. And hopefully this video has been of a help to you and I'll see you in the next world.
More from Dennis

Is Google Killing Websites? The Future of Search, SEO & Web Design After Google I/O

Something we're still looking forward to in Bubble: richer design experiences! #bubble #nocode #ai

Big mistake companies are making right now: firing employees instead of empowering them. #ai







