How to Build HubSpot Solutions for Scale | HubSpot.Extend() 2022

Hey, how is everyone today? My name is Tyrone Falsten. I am the CTO of aptitude 8. I am also a founding member of A Labs, which is a developer house that primarily builds stuff on top of HubSpot. We're really, really happy to be here today to kind of demonstrate some of the things that we have learned and we'd like to kind of bring some of this stuff to light to you. We think HubSpot is an excellent platform to build applications on top of and really more importantly, to build a business on top of. We see a lot of growth. We think that the technology that is, is in place and that is going to be coming here pretty soon. It's going to be pretty earth shattering and we think it's just great timing. So there's a lot of reason, a lot of why, as to why investing development hours and into HubSpot is going to really kind of pay off for us in the long term. Currently, we actually have about seven apps already that kind of cross a few verticals, such as real estate and payments. We also have a handful of utility apps and we also have a few apps that kind of address the service side of things. So like, you know, customer portal or SLA or things of that nature. And so we're always kind of looking and learning, we're always trying to expand what we know and really try to address as many big ticket areas as we can because we notice that a lot of people, when they come over from different platforms to HubSpot, there's usually a lot of opportunity for a developer to kind of go in and either build them something new or help them keep parody with the platform that they're coming from. So today's demo is really a HubSpot stripe connection. If you ever read any of the background for us, you'll notice that we actually already have one. It's called Zebra, but we did not record Zebra being built at all. It was just never, never in the mindset whatsoever. So what we're doing today is really building a HubSpot stripe connection. And we're going to build it in a fairly scalable way so that whether you get one customer or a thousand customers, you have very few worries about scalability and really just kind of show what the level of effort it really kind of takes to build one of these things. Okay, so here are some of the basic questions that I thought I would kind of put up here. And there were questions that we were getting as we were building this thing. And so we're just kind of quickly breeze through them. What are we building? Again, it is a HubSpot Stripe Connection app. And really the idea here is to say, hey, there's some actions going on in Stripe. How do we get that data into HubSpot? And for those of you who do not know, Stripe is a payment gateway. I could say probably similar to a square or authorized.net or PayPal or something that fashion. And so a lot of activities happen as payments occur. Maybe you have transactions that are going through, maybe you have transactions that are being declined, maybe you have transactions that are being refunded. Whatever the case is, there's a lot of activity that happens within a payment gateway. And so there is a very strong desire to get a lot of that information from the payment gateway into HubSpot, where then you can take some actions against it. You know, for example, if a transaction goes through, maybe you then want to email your customer to let them know that the transaction went through, or to maybe say, hey, your subscription has been renewed, or maybe you want to send them something about upgrading, or maybe they're an enterprise customer and you want to treat them nice, or maybe their card was declined and so you want to send them an email for that. I mean, there's a multitude of reasons and use cases as to why you would actually want to integrate your Payment Gateway and HubSpot. So again, not so much a shameless plug as much as it's a regular plug. We do have an app called Zebra that does exactly this, and we have found a lot of, a lot of love for it. So why are we building? We are basically just kind of trying to demonstrate when you build an app, what are some of the scalability things that you really need to probably be building with or concerns that you need to need to address really, from the beginning. Luckily, we build on aws, and so that's what you're going to be seeing a lot of here. We generally try to take a high scalability approach to all of the apps that we build. The fair way to think about this is what happens if my app becomes successful? What if it's beyond 100 people? What if a thousand people, what if 10, maybe 50,000 people use it all all at once? What does that look like? And so while it's really common to have the idea of growing to your needs at the same time, there's a lot of AWS tools out there that will allow you to build scalable things almost right off the bat. And so that's what we're kind of demonstrating here. What will it take about 50 hours of development is really what it kind of takes to kind of build it all out. We pretty much did this in our spare time. Where can I find it? It is not it. While it is actually a public app, if you were to get the OAuth URL, we're not making it public. So this is actually just strictly for demo purposes. You're welcome to take the code, you're welcome to take the diagram, you're welcome to take whatever it is that we pretty much built and use it for yourself. No problem there. But we won't be making it available. How's architecting? So we're definitely going down the microservices route. There's a chart you will see later. We're using a handful of EC2s and Lambdas and things of that nature. And we try to approach this in a way where you can update one thing and if it bombs, the entire application doesn't come crashing down on top of you. So generally speaking, once you get beyond, you know, 100 users, it becomes really important to make sure that you have a way of segmenting development as much as possible. I am not not talking bad about monoliths. Most apps are monoliths and most are just fine. But it is something, you know, if you can architect a project from the beginning, why not do it this way? Especially if it doesn't really cost anything extra. So lastly, what text is being used? So we use Lucy, which is a flavor of Cold Fusion. If you're familiar with Adobe Cold Fusion, this is like the open source version. Both of those technologies are really just Java, those texts really just Java interpreters. We use a little bit of my I s and some MySQL shockingly, this app is really, really bare bones just for this demo. So we actually don't have a JavaScript framework in mind. As you'll see through the pages. I like to think of, this app is basically like the Craigslist of demo apps. So it's very, very bare bones. It's really just here to kind of prove a point that you can do it, you can do it quick, and you can do it for not a whole lot of money. Okay, so the very first thing we need to do is we need to get set up with HubSpot itself. So if you are very, very brand new, then you need to create a developer account. So anyone who has is doing any level of developing on HubSpot, you will actually require an account. And then once you get that, you can actually get what's called A developer account. And your developer account will allow you to create apps. Now this is important. A HubSpot app is not an app in the traditional sense. It is not an app that you are going to download onto some hardware. It is not like a mobile app where it's going to run on some device that you're familiar with. A HubSpot app is simply a web app that has access to a HubSpot instance. That's it. So what happens is you will make your app somewhere on the Internet somewhere, and then you will register that as an app with HubSpot. Once you do that, HubSpot will then set you up with an OAUTH process or a way for you to basically authenticate yourself to determine who you are or who you're making API calls on behalf for. This is really, really important because a lot of people will ask, where does, where does the code go? Where does the app live? Okay, so the code is going to exist probably in your GitHub or whatever repository you're using, but where it actually operates at or executes at is going to be somewhere on your infrastructure. This is crucial to know. Okay, now, right, let's move on. Test account. Once you have your developer account, you need to create a test account. You need to create an app and a test account. So let's do that. Now that you're in HubSpot, you will come over here and you would go to manage apps. Very first thing you do is you want to come over here to manage app. You would want to create an app. This is what we did, right, for our app. Came over here to manage apps, we came over here to create app. And you can see the other apps that we use. Customer service, portal, clone, tech, real city. Like I talked about beforehand, when you would come over here, you would go to create app. This is what we did. You would fill in your app name, you would give it a description preferably. Then you would go over here to the auth section. So the auth section is really all about security, privacy and risk reduction. Right. So if you go with a regular app and there's a few ways you can kind of go about making apps in HubSpot. One is the route we're talking about here, which I will call the OAuth route. Right. I think we're all probably quite quasi familiar with that. The OAuth route basically allows you to say, hey, HubSpot is going to give you a grant code. You are then going to take that code and then you're going to make An API call with that code and with in addition to your app ID your client ID your client secret, you're going to pass all that over back to HubSpot and then in response, HubSpot is going to give you an access token for the customer that just signed up for your app. Now that you have that access token, then you can make API calls on behalf of that customer. That's the way it works. The other route is called private apps. Private apps work a little bit differently. Let me quickly find a test account here. I've actually named one after myself. Not trying to be vain, but hey, someone's got to do it. But a private app pretty much says you can have pretty much most of the things of an OAuth app. And by the way, OAuth in this case really means like public app. It is what miscellaneous people are going to download or are going to use. Sorry. So if you don't know your customers, more than likely you're going to be making an OAuth app. If you're making an app for just yourself, then you would probably do a private app. So real quick, just to kind of scoot over here and kind of show you where the, the private app would be set up. Now that I'm in my test instance, or this is a test instance, sorry, I would come over here to Settings. Once Settings loads up, I'm going to go over here to Integrations. And once the integrations, you'll see I have an option called private apps. Sorry, my machine's running a little bit slow there. Okay, so again, a private app is just to say, hey, me or my company, we're the only ones that are going to be using this app. Right. Probably less risk involved for sure. Probably less load involved in addition to. But the second you say, hey, a lot of people who use my app, I have no idea who these people are, then you want to go down the OAuth route. Okay, so kind of going back here to both apps. Once you kind of give your app a name, you'll then really need to concern yourself with scoping and security. And scoping and security really allows you to kind of set the stage for what your app can and cannot access. HubSpot is currently phasing out the use of API keys, which is good, but you want to basically lock down your app to only request and modify things that you need. This is good for your app because it makes sure that you can only access things that you need and it also reduce your risk. So if your client says, hey, listen all of my contacts got deleted. You can say my app doesn't even use the contact scope at all, so it must be someone else. So you want to basically kind of consider these things as you're building your app. Okay. Once you have your. Once you know the scopes that you want, for example, you would say, I want my app will only affect companies, or only, I'm sorry, read and write companies. Great. Now, what you would need to do is you would need to then supply a redirect URL. And the way this works is it says, hey, HubSpot says, listen, I need someplace on your app that exists outside of HubSpot, of course. Someplace where you're going to be able to kind of do this swap of a code for access tokens. Where is that going to happen at? That is actually what your redirect URL is. Once you put in your redirect URL, for example, I'm just going to put in yahoo.com, see if it likes that or not. Okay. And I've got a couple of scopes chosen. Now I'm actually going to get a. Oh, let me hit the save button here. Sorry. Now, once you hit save, you're then going to get your install OAuth URL. And this is the URL you actually want to hand out to the rest of the world if they want to install your app. If you have a private app, you don't have to worry about that at all. There's no install URL. You get a permanent access token right off the bat. You can use that. But if you're going down the OAuth route, this is what you're going to need. Once this is actually set up, you're actually done in HubSpot at this point. You can now move on to other parts of the app, which is what we're going to do here. As I said beforehand, we are definitely very AWS centric over here at A Labs. It is our primary cloud provider for sure. This demo app uses a handful of cloud technologies that will briefly go through and talk about why we use them, some of the thoughts and concerns about using them and how they help us. Okay, so number one, data source. So we use an RDS cluster primarily as our primary data store. We use AWS Aurora, which is basically just MySQL 5.7 in different scan, and it's a managed service. The thing here is that you really want to consider is that you can always set up an EC2 instance with the database if you want to. The real difference between that and a managed service really kind of comes to a handful of things. One, upgrades, two, scalability of course, and three are our cost. So speaking of kind of number two, especially the scalability part, which is really what we're trying to demonstrate here, we primarily. And if you get an RDS cluster, you'll get a read and a write. They give you a read and write by default. So if you were to set up your own database, you would have to go set up your own master and slave and AWS does that for you. The good thing there is that you can then have scalability rules that say, hey listen, if this particular part of my cluster really a read replica, if it gets too busy, spin up another one. And this is really, really cool because it can allow you to have more databases in play to absorb more load. The downside with that of course is there's a cost involved. So if your database, if your AWS bill in total, let's say it's $1,000, I'd be willing to bet that the RDS part of your bill is about 200 bucks and it grows with usage. And it's also really important that as you kind of get into the scalability part of this of using rds, that query optimization is really key. Because if just spinning up another read replica is not going to help you, if your queries are looking over really big tables and they're really inefficient, you don't have indexes and stuff like that, it can be really expensive really fast. Okay, enough about databases SQs. We use these here as really a way to decouple things. What you'll see here in a few subsequent slides is that we use SQL as a temporary data store. A lot of times the question you'll get is why not just use a database? Well, SQS ends up getting a lot of activity and it ends up being a very temporary place. And it also ends up being a place where our lambdas that we'll talk about next tend to do a lot of their work at. And lambdas tend to be very intense workhorses. And so with that comes a level of high IO read writes. Just a lot of activity in general. And instead of abusing our database which is already busy running the business, we'll just kind of put as much as we can into sqs. Okay, gateways. Now gateways are basically just entry points into the AWS network. We primarily, and especially for the sake of this demo, we are primarily using the US East 2 region. And so we use a gateway to act as an endpoint on the Internet for traffic to come into our aws, basically our vpc. So once it's in there, if you've ever been billed by Amazon, you'll see that sending data in and out of Amazon can be kind of expensive. But once you get it inside Amazon, circulating data around the Amazon network is extraordinarily cheap. A gateway kind of acts as an entry point to get data in the door and then we pass it around to all kind of things like an SQS or Lambda or cluster or whatever the case is. Some of the other parts that we use, even though this is called AWS Lambdas, there's two actual parts that we are also part of this demo that we use ourselves actually, which are EC2 instances and lambdas. And so we use the EC2 instance here. And for. People don't necessarily know an EC2 instance, easiest way to think about it is just it's a virtual private server that you can kind of spin up and spin down whenever you want. Most cloud providers pretty much only charge you for the time it is actually up and running and allows you a lot of flexibility. You can have multiple EC2s, you can have EC2s behind a load balancer, you can have Windows, it can be Linux, it can be whatever it is that you want. But we use it primarily to, to install the app and to help with some session management. Not that you can't do that with lambdas, but becomes definitely a bit more challenging to do it with lambdas, just because of the way lambdas really kind of operate. Finally, we have the lambdas part. Lambdas. Lambdas. Lambdas. You probably heard me talk, say the word, you know, 50 times already, you'll definitely hear it another 50 or 100. But lambdas really are, I like to call them little, very small baby EC2s that pop into existence and really only do a handful of things and then they go away. And just like the EC2 instance, you really only use a lambda from when it's running. It makes it able to have a massive explosion in working processes. They all kind of come in and attack things like a little swarm. And so from our perspective, what we like to do is we like to couple lambdas with sqs with queues and allow the lambdas to basically just kind of all eat through the messages that are in the queue. Because when you have a bunch of lambdas spun up, they can shoot through those messages in the queue really quickly and get a lot done for really cheap in a really short amount of Time. So this is pretty much the diagram of what the demo looks like. You can see we're going to be sending stripe data to our gateway API. We pretty much handed off to a lambda, which dumps into a queue. Generally speaking here. From the lambda to the queues, we're tagging a little bit of extra data. We're doing a little bit of doing some checking here. And then we dump the message into the queue. That queue tends to pile up, especially when, if there is a Black Friday sale, that queue would, in theory, that queue would just blow up really, really, really quickly. And then a lot of messages kind of build up there. And then we'd have another lambda here called the SQS message processor. It would be lots of instances of this that will eventually chew through all of the messages in the queue. And eventually some of this data would make itself, make its way back back to HubSpot to the system itself. Your HubSpot instance, this is pretty much would be like a list of people who have essentially installed your app. So really simple, just HubSpot ID when it happened. You may want to have additional fields in here for maybe like IP address and maybe who the person was who signed up. You can kind of get that from the access token. But for the sake of the Demo, really simple HubSpot ID when it happened. HubSpot configuration. This table here is really similar to the config table. So this is really for your customers. The other config table is really for your system as a whole. But here you have configuration keys or configurations that are set up just for your customers. For example, at a last, we have a ginormous config table for our customers and everyone has actually the same configuration keys, but it's the values that are different. So if you have a customer portal, there may be a config key called page title and one person's may be called customer service. Another person's may be called Joe Smo's Ticket Service. You never know. Again, keys are the same for everyone. Values are what make all the difference. Okay, handle that is, you need something that's very scalable. And so again, lambda, lambda, lambda. Use lambdas for your CRM cards. Lastly, the last lambda here is really to help with polling because we actually have built a Chrome extension that's doing some polling to get message data that can be fairly numerous. And so we use a lambda there too. You can also see your diagram. We have our primary MySQL database and our read replica. Just show what that looks like and also show what is accessing what? We lean pretty heavily on a read replica, especially in this demo, it's definitely the way to go. Your primary data store, it's already got its work cut out for. There's a ton of rights probably going to go to it if you build something like this in the real world. And so you got to give your database a break. Use your read replicas whenever you can. Okay, so just want to briefly touch on a few of the AWS components here, especially the really important parts. Primarily, everyone's business pretty much runs off a database. I just don't know too many people that don't have a database. Whether it's in memory or on disk, on a hard drive or a tape drive, whatever the case is, everyone is in the business of databases. And so this demo app is no different. So again, we have an RDS instance. I definitely recommend it. One thing when you get an RDS instance is that you will get a read and you will get a write database. And what that means is you'll have one database that pretty much you just always save things to. You'll have another database that is going to be more primarily for reading things. And so what it does is it helps you. Helps the right database just kind of relieve the pressure on things. And so these databases pretty much stay in sync, usually to the millisecond, which usually means it's really, really lightning fast. They're generally in the same area, same region, same availability zone, so forth and so on. And so this thing is the workhorse of your business. So it's really important to treat your database right. Again, load is really, really important as you build scalable apps to ensure that your database always has capacity for more and more reads and writes. It's critical. Not only do you want to have a read and write, you also want to take advantage of what's called an RDS proxy. An RDS proxy basically allows you to do network or to say database connections and manage how many connections actually connect to your database. You only have 1,000 connections to your database and then your database would just simply stop receiving requests. Just like a web server can only take oh, so many simultaneous connections. Databases are no different. What you do is you use RDS proxy as a way to funnel the number of connections that may come into play. Now you may ask yourself, hey, is this because there's going to be 10,000 people all using the website? Could be. Very well. Could be. Could also be because you have a bunch of lambdas that are all spun up and they're all doing work. And each of those need to connect to the database as well. That traffic of lambdas that it causes can ebb and flow. You need to be able to create as many constants as humanly possible. RDS proxy is something that we definitely recommend in addition to. We definitely want to just look ever so briefly into the database tables that we have here. The definitions for these tables will definitely be in a repo somewhere. We'll probably post them up at some point. But just ever so briefly, here's what we're looking at. We've got an access token log. This is part of the OAuth process. As you are getting access tokens, you want to make sure that you are saving them someplace. Maybe you keep a log to ensure that when you're going through the refresh mechanism. Because you do have to refresh them every 30 minutes. So it'd be something where you, hey, I need to be able to verify that these things are being refreshed on a very timely basis. So you have to log for that here. Let me just do a quick detail so you can kind of see what this looks like. None of these are actually really complicated or anything like that. In fact, most of these actually, for the sake of the demo, aren't necessarily indexed, but you will definitely want to do that. We've got our access token log. The next table here is the config table. The config table pretty much acts as the primary data store for everything that's systemic. If you ever looked at a WordPress instance, that's usually a key value pair, no different here. All the config keys here are really just kind of, you know, to manage the domain and maybe you have your credentials saved here and things of that nature. Things just for the system itself. Your HubSpot instance, this is pretty much would be like a list of people who have essentially installed your app. So really simple, just HubSpot ID when it happened. You may want to have additional fields in here for maybe like IP address and maybe who the person was who signed up. You can kind of get that from the access token. But for the sake of the Demo, really simple HubSpot ID when it happened. HubSpot configuration. This table here is really similar to the config table. So this is really for your customers. You know, the other config table is really for your system as a. As a whole. But here you have configuration keys or configurations that are set up just for your customers. So for example, at A Labs, we have a ginormous config table for our customers and everyone has actually the same configuration keys, but it's the values that are different. So if you have a customer portal, there may be a config key called page title and one person's may be called customer service. Another person's may be called Joe Smo's Ticket Service. You never know. Again, keys are the same for everyone. Values are what make all the difference. Pretty simple stuff here. There's nothing beyond comprehension. We've got a notification log. We're actually going to dip into this a little bit later. This is going to be where when a transaction happens, as our lambda processes the event, it's going to save that as a notification for someone else to read for later. And this is what that table is, just a log of notifications. Finally we've got a. I shouldn't say finally, but close to. We've got our sales rep table, which currently is just me. And ultimately these are really just kind of HubSpot users. We've got our Stripe webhook log, which is just a log of the stripe events that are coming in the door that are being read. So beforehand, when the stripe event comes in, not only do we save it to the queue, we actually also save it to the database just for kind of long term storage, especially also helps out when it comes to debugging. If you need some messages to kind of test with, you would now have a giant table of them. And finally our transaction log is exactly that just kind of holds the transactions that have occurred and saves them to a table so that we can understand like hey, this, Remember the point of an app is to be able to say, hey, you were involved as a part of this transaction that happened and what do you know, maybe there's a commission to pay out. So we've added a couple commission fields here to the table just to make things a little bit more exciting. So this is all that's really part of the demo from a database perspective. Again, this database is an RDS instance. We move a really small one. So it's really cheap to run. I would definitely say growing to your needs, but mega straightforward. Only a handful of tables, you'll be able to get a majority of the job done for any kind of connection. Or maybe it's not stripe, maybe it's authorized.net in HubSpot, maybe it's square and and HubSpot. But a lot of this is going to be the same. Now we need to get into a stripe account. At this point you would want to go over to stripe.com and you would want to create an account. Don't worry, you're not going to really do any real damage in the real world, because with every Stripe account actually comes a test mode. And so you can then create tons of fake contacts, subscriptions, products, you name it. But ultimately, we need to understand how we can get data from Stripe and to our app. That's what we're going to do right here. Okay, so the things we want to really focus here are getting our API credentials, creating our webhooks, and then creating a transaction. So here the API credentials are going to be your public and your secret keys, and eventually you're going to add those to our app, to our demo app. You'll see that as part of the installation process. Once you do that, you'll then want to basically add in the web hooks, because you do want to say, hey, Stripe, I want to send my Stripe data to this particular endpoint so that it can make its way into HubSpot. And then you actually want to create a transaction which will create the event so that Stripe actually has something to send. Okay, so now that we have our app created, let's go ahead and do a few changes. So the things we'll really kind of need to kind of keep in mind as we're building this is that the app itself, remember, it just kind of registers your externally lived app with HubSpot, but we need to kind of need to do a few updates there. So now that we have it created, next, we really want to talk about what the CRM card is going to, is going to come from. So the CRM card basically allows you to take external data from someplace on the Internet and bring it into HubSpot, essentially in the form of an iframe. So because it's in the form of an iframe, and because CRM cards don't really interact directly with the HubSpot UI, I mean, it does, but in a very, very limited fashion. You have a lot of control over what happens within this CRM card. So the CRM card has, has two things that you need to kind of keep in mind. One, when a CRM card, when a page that has a CRM card on it, when that page loads, HubSpot will make a HTTP call to somewhere that you specify to grab some JSON that tells HubSpot how to build the card. That JSON payload tells HubSpot, hey, this CRM card has a button or has a title or has text here, or it has numbers here, or it has links Here, that JSON is basically the blueprint for your CRM card. Now, if you actually want to show, say, a window, for example, that is where the iframe comes in, and you would specify the URL to that iframe in your JSON blueprint that I just spoke about. Okay? So the app will definitely cover that here in a bit. Next is modifying deals for this app. We actually modify the deal, the deal object, and we're going to dynamically add a new field called Stripe subscription id. And we're doing this to kind of show a few things that one, you can actually modify standard objects to. However, for the most part, however, you need. Two, you can actually modify them dynamically. You do not have to do this through the HubSpot UI. So what we do here in our app is we actually modify the deal object upon install. So part of the install flow is not only just the trading of OAuth code for access tokens, but once we have that token, and because we already have our scopes and permissions set for what our app is allowed to do, we then go ahead and actually modify that deal object by adding the field that I spoke about. Once that field is updated, when Stripe data comes over From Stripe to HubSpot, we save that subscription ID from that event to HubSpot. This way the HubSpot user knows, hey, here comes a transaction. What was it for? What subscription is this thing associated to? What's it linked to? We save that right on the deal object. Makes it really easy to understand to help better associate your HubSpot data from your Stripe data. Okay, finally, the last part of building this demo app. What do we do here? We built a Chrome extension. And the Chrome extension's point is really to do two things. As stripe event data comes into our app, the app will then basically save essentially like a human readable message to a table that we showed earlier called notifications. Our Chrome extension basically hits a lambda, which polls for that notifications table and pulls back messages that belong to the user. And so we went with a Chrome extension because we wanted something that really wanted to make sure that you didn't have to be signed into a specific site. And Chrome extensions kind of give you a bit more high level, kind of globally feel, that is, you can kind of be on different pages across the net and you can still kind of get these notifications. I know that we did a very similar, similar project in a previous life, and the sales reps absolutely, positively love knowing where their customers were on their site or when transactions had occurred and they knew when they were getting commissions and things of that nature. So what happened was the sales reps became very closely aligned with what was kind of going on in the transaction world. And the sales reps were just crazy motivated to kind of see bing, bing, bing. You know, basically for them it just meant money kind of coming in and they didn't have to wait to the end of the day, they didn't have to wait till the end of the week kind of see what was going on. They were really not real time, but you know, not, not far out either. And so the Chrome extension is pretty helpful. So again, we created a Chrome extension. It does get installed manually. Granted, this is a demo app, you know, so you can load what's called a unpackaged extension. That is you can basically hand someone like a folder or a zip file and they can install the Chrome extension themselves. And then our Chrome extension, actually it's very, very simple. It's just a little bit of JavaScript and some HTML and it pulls a lambda that we have set up every 10, 15 seconds. So nothing heavy. We did consider WebSockets, but didn't want anything really getting kinda too connected, especially for the sake of the demo app. It was just like we just kind of go with polling. Makes a lot of sense. We didn't want to add any additional layers of complexity because we really hope that other people go out and build this thing themselves and kind of improve upon it. And then the notifications, they're actually Chrome notifications. So if you've ever been sitting at your computer or maybe for surfing on the net and then some website says we'd like to send you notifications, you say no, pretty much those. So it will pop up pretty much on top of everything. But at the same time, you know, you can always turn these things off, you can always uninstall the extension if you want, but having that kind of almost real timey connection with what's going on in the transaction world, again, it's amazing. And so for our notifications, ultimately what we did was we made them clickable so that when the notification came in, you could click the notification and it would take you to the deal in HubSpot, so you can exactly see what deal was affected. And then ultimately you'll see all of that juicy stripe event data that got placed on, on the deal itself. So that is actually the app itself. We'll make another video just kind of briefly going through the install process and maybe what it's like a little bit later. But that is the app. Again, it took about a week or so to build. Nothing crazy, you do need to know some cloud technology for sure, or at least it certainly helps. We did borrow some components from other projects to make this happen, but ultimately what you would end up with is an app that is actually really cool and gives a lot of your HubSpot users a lot of insight as to what's kind of going on in the stripe world and it gives it to them in a very fast paced action. So very much like a basketball game will definitely keep your attention. Really hope you guys enjoyed this app. Looking forward to any questions you may have that come afterwards.