The below transcript has been auto-generated for your convenience. Please reference the source video/audio for direct quotes or to clarify any errors.

Speaker 1: (00:10)
My name is Tyron Fosen. I am the Chief Technical Officer at Aptitude eight. I head our product development and, um, basically all the things that are kind of really overly techy. I'm probably involved in some way or somehow. So, uh, building HubSpot apps is something that we absolutely, positively love to do, and I'm gonna be talking a whole lot through this. Uh, just a side note, my pronouns are he, his, and for, for, for the impairment. I am also in a small office with video game stuff behind me, um, because I'm very geeky like that. So I'm,

Speaker 2: (00:46)
I am Dax Miller. I am head of Practical eight Laps. So I kind ideate and think of concepts, go to market strategies, uh, branding, visuals, video, uh, pretty much all of the forward-facing things for all of our apps. Uh, Tyran builds it, I break it and kind of click Global Wrapper around it. Uh, so everything that I'll be talking about will be more on the, the, uh, go to market side, uh, how to get the app in the store, uh, how to orient the ecosystem, whether you do or not, um, kind of the, the implications of that. And a little bit about some of the strategy of how brand and how to put something together to make a commercial that, uh, back to you. And Timer is awkwardly on mute.

Speaker 1: (01:32)
So Island, uh, so this first session, we're not building the app of this session. That's really coming the next session. Just wanna make sure that's, that's very clear. This is very high level and this is really for developers and stakeholders who are thinking about building an app. So we'll be talking about, and I'm just gonna read this straight off the list here, translating your concept into a viable app. Cuz everyone has an idea. If you are a developer, I bet money someone in your, your friend or a family, just like, Ooh, I got this idea of short app. Oh, oh, oh my God, I got this great idea. Have you ever thought about that? And they don't all come out to, they don't all pan out. So there, there's a reason for that. Uh, we'll talk about setting up your developer account and getting going. How to connect your app to HubSpot once you've actually created it. And a lot of this is also gonna be the development and business considerations. Before you actually start clicking, be clacking on the keyboard, there's a lot of things that you need to talk about or think about or consider, uh, before you actually start developing yourself or painting someone to develop things full.

Speaker 1: (02:32)
Alright, translating your concept into a viable app. You know, they say ideas of work pays. So kind of going back to what I was saying beforehand, when everyone has an idea for an app, oh, next slide is fine. Um, a lot of those apps don't pan out. When you are thinking about making your app, the, the number one thing you really need to be considering is, what problem does it solve? Whoever's gonna install this app, they're installing it because they either think it's going to help them do something bigger or faster, or understand something that they didn't understand beforehand. There needs to be a true benefit for it. Um, and so you need to ensure that you're definitely solving a problem. Um, and, and it's always good if you can, if it solves a problem for yourself, it's even better cuz you're almost kind of, um, solidified the idea.

Speaker 1: (03:19)
But you need to make sure that you're salting problem. How long will it take for an mvp? You do not want to have, um, a perfectionist mindset when it comes to app development because you will simply never finish it. Uh, this is also known as feature creep or scope creep. And you need to have a very delineated way of doing things to make sure that your app gets out the door and then you can iterate on it and then you can get some feedback and understand what people really want. Do you have a budget? Uh, if you're rich, grit, um, I'm not quite sure what that's like, would let, let's connect after the meeting. We'd love to see what that's like. But, but kind of going back with how long will it take? Uh, a budget will for sure set you straight in terms of how long you can fund the development of an app before you absolutely need to have it out into the wild, especially if it's revenue generated.

Speaker 1: (04:15)
How complex is the app? Um, is your app something where, Hey, I'm just showing more contact information. Or maybe your app needs to connect to, to some outside service. Maybe your con connect, maybe your app is a connector to BigQuery or something to that fashion. Um, maybe your app is gonna have to deal with spikes in load. Maybe your, there's a lot of considerations. Um, and you will want to make sure that you know the true complexity of your app before you start developing. Uh, otherwise you will for sure find yourself in a situation where your oil is kind of like behind and you're doing a lot of discovery as you're building. Uh, that will cause a lot of problems and delays down the line. Uh, can you measure success? You want to think about some kind of metric. Maybe your metric is, can we get a thousand people to install the app?

Speaker 1: (05:06)
Maybe the metric is, if people use my app, they'll be 20% more efficient in doing some particular activity. You want to have something where you can, once you have the app, you can measure how well it's performing in terms of what problem it's supposed to be solved, who will manage at maintenance. So 60 to 80% of the cost of an app generally comes after launch. So you spend some capital to actually make the app, but then once it's out into the wild, that's when a lot of times you discover, Hey, there are people who want feature X or Y or Z. Um, this particular thing, we don't need this particular thing is broken. All of that generally costs money. Uh, and then there's a question of who is going to do it. Do you have an external development company? Do it, uh, do, is it gonna be something that's in-house?

Speaker 1: (05:55)
A lot of times people have an external company that does the development and then once it's over, they maintain it themselves. So you need to kind of have some idea of who is going to be rooming this bad boy. Um, once it's out there, will there be customer support? Um, so generally, if an app is small, uh, the customer support is usually the development team. Uh, if your app is large and serves a very large audience, then that can really no, be longer be the case. Otherwise, your developers will never have the capacity to develop. They'll just be on, uh, customer calls all day. All leave the entire time. So you may need a strategy for who was actually going to help people with the app once it's out there while maintaining, uh, developer momentum and what technical skills exist on your team. Um, this can be a mix of what technologies that your team currently works with. It can also be a question of senior rich. Do you know their juniors or their senior developers, so forth and so on. Uh, does your team need a cloud architect? Do you have it? Do you need it? Um, does your team need to have really good database skills? I mean, you want to have, you want to know these things, uh, before you actually start your apps today, you can actually build the right team to build the right product. We'll go to the next slide.

Speaker 1: (07:20)
That's one. This is all on you way.

Speaker 2: (07:23)
So, and one of the things that we always have to consider once we're kind of ideating or thinking, is this worth coming out? Um, do we have something to do? Does this work out? Um, this was, uh, a great example of this is our, our customer was one of our first apps that we launched, uh, couple years ago. Um, we had to go through the idea of when is HubSpot going to come out with this? Um, does this have a purpose? Do people need this? You know, is the community forum where people complain about this being, uh, something that they need? And all those pointed a yes, but we understood that when we talk about commercialization a little bit later, that HubSpot is a platform and they may have, uh, something on their way to replace your app if it, uh, doesn't specific cut thing.

Speaker 2: (08:00)
So you really have to differentiate, see how viable this is before HubSpot does something about it or, and or afterwards, uh, the end user experience. So we're gonna be talking about the, the limitations of HubSpot and also what's great about HubSpot when building an app within the, within that ecosystem. Um, will people be able to utilize this directly in the CRM on a CRM code? Is it something that's going to have to have your own admin and your own login to do some other specific interest? Because the mutations set currently set on the up on the platform. So, so it's about understanding not only how the end user experience looks, but where is it User stories are super important to understand where and how you actually build this app and to as we'll learn a little bit more later on as well. This app will not live in Hooks fund.

Speaker 2: (08:47)
Uh, so there's gonna be a lot of things you have to talk about to understand, well, how a user interacts a market demand. So is, will people pay for this? How much will they pay for? Um, one of the key things about building products is that your product needs should be a part of someone's worth. I'll say that one more time. Your product should be a part of someone's worth. That means it's get replace. That means it's going to, you're gonna have luxury. That means it's a part of the way that they do business and they don't wanna change that because it, it helps, it saves time, it saves money, it saves energy, it saves Tiffany Black, anything that's happening. What type of demand is that, uh, is available. So looking at if this is building an app for one of your clients, um, they probably lawyer you up about something that they can't do and really want to be able to do it.

Speaker 2: (09:31)
Or you can look in the community forums and you see that can, the hotspot community as a whole is begging through this, this, uh, this product, this, this feature. And this is something that you could clearly build and extend HubSpot. Um, long-term value. How long do you have? Uh, do you have a target on it? Does it have a target on its back? A lot of the ideas that we have early on in the AIST and a lab days where how long if we, if we come out with this, it takes two months to build or three months to build. How much, how long can we profit from this? Or how long will it take to recruit the money that we invest in so that we could use it for any other, uh, method? That's a really big deal, especially in this ecosystem when dealing with something commercial.

Speaker 2: (10:10)
When you're dealing with something for a client, it's about is it going to, is it going to be outdated? Do you need to build it marginally so that if they, they won't keep asking for more and more features and they end up building kind of a kind of garble tangled mess of spaghetti coat. Uh, so understanding what the long term value is, what's gonna happen here once they have this are more, they're gonna less, that's some big things to understand on the being realistic. And usually tyro's the one that helps me kind of be down the earth. Cause I'm just long here. It's usually a problem. We go to the next slide.

Speaker 1: (10:45)
All right, setting up a developer account. So here, here's the thing that you really need to know, uh, when you're setting up a developer account. Uh, and you will see screenshots of this stuff, uh, after the fact. You need a HubSpot account to do anything. And a HubSpot account is basically the same HubSpot account. Pretty much everyone has, in fact HubSpot themselves actually use HubSpot. So what do you know? But you definitely need this once you actually create your account. Again, granted just full transparency, it's not that you necessarily need to use it, you're not gonna be necessarily managing contacts and deals and tickets and things of that nature, but it, it's, you have no choice but to have a HubSpot account, okay? Once you have created a HubSpot account, once you are inside HubSpot, you can then create a HubSpot developer account. And your developer account is essentially your gateway to development. It is going to be where you actually get your API keys from. It's going to be where you actually register your app with HubSpot. Uh, it, it's going to be, uh, when you go to put your listing in the marketplace, this is where you're gonna start from as a developer. The HubSpot developer account is where you are going to spend a lot of your time.

Speaker 1: (12:04)
Once you actually have an app, you can now create test accounts. So, and these test accounts look just like your basic HubSpot account. Uh, there's really no difference. Uh, they're usually all unlocked in enterprise. So you kind of get all of the features that you would need. Uh, the true difference between a test account and your basic HubSpot account is that your test account can ex expire if it's not essentially getting, uh, attention or usage. Um, in addition to, you need to make sure that you are not confusing the two cuz it's really easy for people to think that I can access my test accounts through my basic account and it's just not true. They are, they are indeed different accounts. You just simply have control. And then once you are all set up, you'll get a developer API key, which we would talk about, uh, that is gonna help me do some development, uh, things.

Speaker 1: (13:01)
And this developer API key is shockingly a little bit separate from a account API key and separate from, um, any ol keys or anything like that, your developer key is the special key that you all use in special occasions during development. So I just wanna make sure that's clear. We'll talk about it here in a little bit in just a bit. Alright, how we connect your app to HubSpot. The number one question we get is, where does a HubSpot app live? And it lives wherever you host it. So a HubSpot app is not a traditional app in the sense of, Hey, I've written all this code and now I'm gonna download it onto someone's phone or I'm going to include it into my WordPress app. That is not the way it actually works. A HubSpot app at its most basic is just simply credentials that you use to make a pi calls to someone's HubSpot instance.

Speaker 1: (14:02)
That's what an app is. Where it lives is totally up to you. What it looks like is totally up to you. Um, but it it, it is kind of crucial to know that because it really is different than the most traditional ideas that people have when it comes to application development. How do you connect to the app? Oh, uh, back on the slide please. Uh, so there's four ways to connect to the app. There's the API key, which I've made us spoken about briefly. There's oof, there's a private applications which are new to, uh, HubSpot themselves, and there's also the developer api I key, we'll get to all these in the next slides.

Speaker 1: (14:40)
Alright, the very first credential or way you can connect to HubSpot, and when I say connect to HubSpot, what I mean are, what I mean is making API calls. So you make API calls, um, to basically run product operations on someone's HubSpot instance. Generally speaking, the quickest way to start development is going to be with the API key. So if you're in your HubSpot and you go under settings and you go order integrations, you'll see an API key setting. The a API I key indeed gives you God access to the entire HubSpot instance. That is, you can do, you can add contacts, remove contacts, deals, tickets, uh, timelines, any kind of object and you can think of that can be manipulated via the API I you will be able to do, um, with the API key. Uh, so the API key is, is good in the sense that it helps you get started pretty quickly.

Speaker 1: (15:39)
Uh, if you're tr if you have done any API work beforehand with various integrations, this is really no different whatsoever. Uh, HubSpot themselves are actually trying to get people to kind of move away from using API keys. Um, and instead they will prefer you to use either oof, um, or private app keys because the API key comes with an inherent risk. Then that is, if I give someone my p i key, they have God mode. If something goes wrong, they're the very first people you're gonna go towards, uh, because it just gives so much unfettered access. So generally speaking, you will want to use the API key maybe just to get started for development out of its simplicity and ease of use. But once you get your application into the wild, you don't want that, you want to reduce your risk. So you wanna move away from, um, using an API key and API keys. The way you're using an API call is really, really sensible. It's just a query stream key value pair megas.

Speaker 1: (16:44)
Next slide number two is oof. So if you are familiar with, with the oof process, um, HubSpot, instead of using an API keys, you can basically get an O off token. Um, if you're familiar with the O Off process, you basically get a code, you give that code back to HubSpot in, uh, with a few other parameters. In exchange, they're gonna give you an access token. That access token is what you will use to make a API calls. So instead of having the API key in, uh, the cruise strength, you will have this access token and it'll be used in your headers. It uses the authorization authorization bearer header. So very common. And that token is really only going to last about 30 minutes. So you will need a mechanism in place to refresh tokens every 30 minutes. Um, when you create your app and you set up this OAuth, you will then be asked to basically set permissions.

Speaker 1: (17:43)
And that is, Hey, I'm making this app, what all objects can it read or write to? And you will basically have to list that out. Once you list that out. HubSpot is going to give you an install link and it's using that install link is where the ALT process to eventually get the access token will begin. Owat is the way to go. If you're making a public app, um, it definitely limits the risks that you have. And in terms of if something goes wrong, you don't want to jack up someone's HubSpot, it also ensures to the customer whoever's gonna use your app that you're only accessing the things that are needed. So part of the, the O Off process, um, customers will basically be shown what permissions your app is being given to and what they can actually, what your app can actually, uh, create an add an update.

Speaker 1: (18:35)
Um, oh, sorry, back one slide. Um, yeah, so with that comes API limits. Now the API limits are pretty high. I I think for, if I'm remembering this correctly, someone correct me if I'm wrong, you get about 500,000 a p I calls a day, which for sure handles, you know, about 99% of all the people you're really gonna come across. Um, that limit is tied to the app. It's tied to a combination of the app and the, and the customer who actually has it. Um, so for example, if I am, and this is, this is a bit of a caveat. If I'm hitting, if I have an app and I it, it, it updates contacts and I hit that 500,000 per day limit, I can actually create another app, uh, that will update those con update those contacts, and then I have 500,000 more calls. So you didn't hear that from here. You didn't, you have no idea where you heard that from? Uh, that found the secret. That was the, that was the secret. Yeah. Um, but API limits are tethered to that app.

Speaker 1: (19:38)
Next slide. Alright, private applications, private applications are made for when you are creating an app, but it is not for the public. Hence, you know, the work private, uh, it gives you the ease of an API key. Uh, so you don't, you don't have to worry about the whole oof, uh, token refreshment part. Um, at the same time, it is very new to HubSpot and it's so it is still mature. And so I say that because one of the things that you can't do with a private app is use c r M cards, which is pretty critical, especially when it comes to integrating your app or maybe some UI you have that you're hosting somewhere and bringing that into HubSpot. Um, but private apps are for sure maturing. Uh, they are really good to use because unlike the API key, there are permissions that have to be set up when it comes to a private app. So you definitely get to protect yourself and the the client gets protected from many operations that may potentially go wrong on your side. So, uh, but this is for sure the, the, the way HubSpot will prefer you to go as API keys. Their usage is never gonna go away, but it's much preferred, uh, it's kind of being depreciated in a way. Uh, and private apps are the, the better route to go.

Speaker 1: (21:01)
Alright, developer API key. Um, yeah, yeah, no, that's, see your Davis, their do this, uh, developer a v i key. So the developer a v i key is a bit of a, um, what was it? The black swan. I'm trying to think. Ugly duck. Uh, in that you really only use it as far as I can tell happen to be wrong. Al, take case. Um, when it comes to running front operations on workflow action definitions, this is definitely a cart before the horse, but if you ever create an app and your app needs to show some UI within a person's, uh, workflow, that UI is generated from some J sig. And when you go to upload that J sig to HubSpot, you need your developer API key. Um, and then it makes sense in some way because hey, we do want to kind of get away from API keys.

Speaker 1: (22:02)
Um, the the private app, you think it'd be there, maybe it's coming, then it's happy. Again, tell me if I'm wrong, um, would would be great if we could do it there, but for right now, when it comes to managing those workflow UI parks, you'll need your developer a api. I key, um, that that's the, the only situation I can really see it in right now. But I do want to specify that the developer API I key is absolutely not the regular a API I key, nor is it the a API I key you get from using a Prime app. It is its own thing. So just wanna make sure to, uh, reduce any level of confusion there. Excellent business decisions to make based on the app audience. I'm going to share my screen.

Speaker 2: (22:55)
Uh, um, before you jump into the, the diagram, kind of the business news case, I going, uh, call had a question about, uh, private apps. So I know I'm jumping ahead of the QA section, but he said, would you use the private app way authenticated to create WebBook to listen to events on certain objects? Lulu, I care about your answer, I want to throw that out there first.

Speaker 1: (23:15)
Yeah, I mean the, the, the answer is yes. I mean, that's, that's as simple as it is for sure. You, you will always want to, if you can, uh, use web hooks as much as possible only because you really want to avoid polling. And, uh, yeah, to answer your question, yes, uh, especially that'll become helpful if you are concerned about maybe GDPR or HIPAA or something that fashion. Uh, I'm actually gonna talk about this in the next slide, but, um, the, the web are for sure the better way to go when it comes to getting event data out of HubSpot that is not based around the workflow.

Speaker 1: (23:55)
Uh, do we have any more questions we want to talk about before we kind of dig into this? I absolutely don't mind it. Nope. Okay. Once gone twice. Great. Share, gimme one sec. Okay. So this is the decision tree that I've put together, and it really is there to kind of give you a, a feel of things that you should be considering before you start developing anything. Or you may have heard me a deck say, click to be clacking. That means a lot of typing on the keyboard. Um, every, every stroke on the keyboard is someone's time or potentially someone's money. So before we, we wanna try to minimize that as as much as possible. And we wanna light ourselves up for success as much as possible before we actually start developing. Um, when you start developing, I will tell you as a developer myself, uh, there is always going to be surprises.

Speaker 1: (24:50)
There's always going to be something that you missed or didn't know or didn't understand, or maybe wasn't available when you first started planning that. It's just the cost of doing business around development. Uh, and so we want to make sure that we nail as many things as possible before we start that process. Clickity clock is a technical term. I love that and I know that, but, uh, let's do that. So number one, who is this app for? Um, a lot of developers work for companies that are not development shops. I'd say it's probably mass majority developers. Um, then you have your development shops, right, who actually build apps for the public. But if I'm building an app, the first thing is who in the world is this gonna be for? Maybe it's for my company. If it's for my company, then private app makes a lot of sense.

Speaker 1: (25:37)
I don't necessarily need oof. Um, not that you can't use it, but private app is gonna make a lot of sense here. Um, we're not necessarily, we're worried about more about extensibility than we are scalability. Um, and we want to try to keep our development probably as as simple as as possible. Authorization methods. One you like I was kind of saying in a few slides beforehand, um, the private app was basically gonna come with its own API key, so that makes it actually really easy. You can use the private app key or you can use an API key here. Again, API keys do give you god access. Private apps are much more locked down by permissions. They will both do the job. Um, and granted you're not making an app for the public, you still want to go down the private app route. Um, again, a v i key, lot of risk, private app, less risk.

Speaker 1: (26:30)
Um, the architecture of your app itself, more than likely is going to be a mile lift, which is what most apps are in general, uh, at least, you know, sad space or web-based apps. Not that can't have something more complex, but of course you always wanna build into your needs and monoliths kind of gets you up and running as soon as humanly possible. Um, if you're thinking it's gonna be more complex, maybe you wanna go with service orientated route right off the bat. Definitely increases the complexity. Uh, generally speaking, private acts aren't nearly as big and not as complex. Um, so it would be something that you would maybe want to maybe consider, but more than likely monolith is where you're gonna be developers and support. So when you have a small app, more than likely your developers are your support team. Uh, when tickets come up, they usually go directly to the developers or maybe they go to some kind of scrum master or someone who's in charge.

Speaker 1: (27:27)
But generally speaking, there is not a lot of room between the customer slash stakeholder and the development team. This is very, very normal. Happens all the time. I mean, you generally use something like Jira, something like that to do your organization parts, but that's just the normal setup when it comes to databases, generally speaking, um, scalability is not so much the concern there. Um, you're all, you're generally always going to have your own database from whatever company you're working for. You've got your data store and now you're extending yourself to HubSpots. There's another one. Um, but when it comes to data stores and you interacting and exchanging data with HubSpot, there are a few things you may want to kind of consider. Um, is GDPR or is HIPAA something that you need to worry about? Uh, kind of going back to the question that was just asked, do you need to be listened out to WebBook so you can have these things removed right away?

Speaker 1: (28:22)
Uh, more than likely your contact data is gonna be in your golden source, which is gonna be your company's database. And that should be reflected here in in HubSpot just to make sure you're doing things the right way and you don't, you not gonna come across any particular issues. Uh, keep in mind that HubSpot themselves will tell you right away, they're not HIPAA-compliant or anything. So a lot of the compliance stuff is totally on you to make sure that you are doing things, uh, the right way. Uh, and then subscribe to web hooks for deletion. So we got a little bit ahead ourselves. I love that kind of thinking. Someone was already thinking about it, but, uh, what, um, I'm gonna look at the questions. Chad, do we see anything, dash, do you see anything, uh, questions you may want to throw out there before I move into the other audience partner? No,

Speaker 2: (29:15)
No, no questions yet. I do wanna just make sure that, uh, yeah, we're all good. Let's keep it moving.

Speaker 1: (29:20)
Sweet. Okay. So the app is not for myself, it is for a company. It is for, it's not for a company, it's for the public. This is where things begin to kind of change. When you have a public app, um, there are a handful of things that you really want to start considering. One, you are probably not going to know what data is flowing through your app. So we go from public app straight to cyber insurance. I kid you not, this, this will be necessary. Uh, especially if you're looking at contacts. If you're looking at deals, deals generally contain a lot of proprietary information around the company's functions and customer base and things of that nature. Um, customers can kind of, then they should be worried about where that data is going. Uh, is it being stored? What's going on with that? Cyber insurance is gonna be something that, uh, you, you want to have that's gonna be your friend in the event of, uh, things go wrong.

Speaker 1: (30:13)
Um, full disclosure, if you are indeed dealing with customer data, which you will be, you want to not persist that in your own data store. You want to keep as much data as humanly possible in HubSpot. Maybe it's coming into your app and you're doing some level of manipulation and then you are sending it back, or you need something to kind of consider, maybe you need to purge that data. If you are persistent it, you wanna purge it every so often and you want to ensure that your customers know, Hey, listen, um, I'm not, this is, this is your data. It's not mine. We only use to do processes, X, Y, and Z. Uh, you need to give 'em that reassurance and make sure that you're not keeping that stuff. Uh, when it comes to authorization, oof is for sure going to be the way you want to go.

Speaker 1: (31:00)
Uh, we have seen apps where people request, um, users API keys, uh, which is outright scary. Um, because you do not want God access to a lots and lots of instances. It sets you up, it sets you up for a lot of trouble down the line. Uh, then having the bid, you don't have those guardrails keep you in place if something in development goes wrong, uh, you really don't want that. So, o o office for sure gonna be the way you want to go here. And with that, keep in mind the oof tokens expire every 30 minutes. So whatever app that you build, you will have to build a mechanism that refreshes these tokens every 30 minutes. And those, those to those tokens need to be ready at any given time. Cause you never know when a client is going to use your app, which is gonna make those API calls in the background.

Speaker 1: (31:50)
Um, one thing we'll think about here is does your app process workflow messages? This is crucial here because it will really help dictate how complex your app needs to be. Um, the number of messages that come out of the HubSpot workflow engine can be tremendous. For example, we have an app called Associate that will basically do a bit of a dynamic lookup. For example, you wanna associate a contact to a deal and let's say the contact has a company ID field and the deal has a company ID field. And then what we can do is we can look, we can look at that contact that comes through a workflow and then do a search for all the deals that has the company's of the contacts company id, and then we can bulk associate it. You cannot really do this with a single server because the number of messages that, uh, message activity that comes out of a workflow is tremendous.

Speaker 1: (32:51)
And so you then start to need to think about, um, a microservices architecture, which will come with decoupling and maybe cues and scalability around your, your data store and cloud architecture, things of that nature. So microservices is going to be something you are, you're gonna for sure have to work with and with Mark, with micro, ah, my gosh, microservices comes a handful of things to kind of keep in mind. Um, so generally speaking, if you a dev team and they've been making, let's say, PHP apps for, and this is what they do, once you get into the microservices architecture part, you're probably gonna have to deal with cloud architecture, which means you'll need a cloud architect, which means that your skillsets for your team kind of has to expand. You need to determine which cloud service you're going to go with. You need to understand, um, the limitations, maybe need to understand the cost that go with that. More than likely, this is going to be a very complex app. So the seniors on your team is gonna really expand when you're dealing with a private app, you could probably just deal with junior to medium, develop junior to medium level developers. When you're really talking about large scalable apps, more than likely you're really talking about senior developers. So that means that, that more than likely the cost of your app is gonna go up.

Speaker 1: (34:12)
Um, so what if your app does not depend on workflows, right? Okay. Then it's almost like a private app again. Um, maybe you can probably go a monolithic, maybe you're thinking about service oriented. Um, it, it, you want to try to grow into your, your, your, your knees. There again, uh, you'll more than likely be able to kind of retain your development team. Really probably won't need much augmentation. So whatever team you got is probably gonna be just fine. Kind of circling back up here, um, is the, is the, is the, is your app revenue generating? Okay. So if your app is revenue generating, it begins to really kind of change the way you will start looking at development. Um, if you have a roadmap, which you will for sure need one, especially if you wanna stay competitive, you need to make sure that your developers can always develop and there are not also full-time support people.

Speaker 1: (35:13)
Um, this will become crucial because as your development team starts to serve more people, if you don't have like dedicated support, and granted, this is much more of a, you know, six months to a year out thing, but it's something to really consider. If your developers are basically inundated with being support people, it will grind development to a halt. And so you really need to kind of be considering how that is going to impact things. Um, you need a v1. Um, if your app is generating a revenue, more than likely the app revenue is also going to impact how things get developed, how things get developed, what parts are getting developed, how expensive are these particular features we wanna do. You need to think about what's it gonna take for me to get V1 out the door, um, because we may need to make money. And in addition to the HubSpot ecosystem is growing, there's a ton of people making that you need to get out there as soon as you can. You'll for sure need a roadmap, especially if you wanna stay competitors, um, because competition is coming from all angles. And to stay ahead of things to make sure that you are really, uh, thinking about extensibility, you wanna join as many HubSpot betas as humanly possible, even if they don't necessarily sound like they can, are directly concerned to your app.

Speaker 1: (36:25)
Um, dev team is support team. I think I actually kind of spoke on that, so a bit of a mistake. Okay, so if we're talking about, uh, a public app and we're also talking about data stores, um, then things tend to kind of get changed up a little bit. Um, you again, kind of kind of going back to a point I was saying beforehand, you do not want to persist a client's HubSpot data in your database. You, you truly don't want to. Now if you don't have to, if anything you want to save maybe a customer ID or a deal ID or some data that gives you a lot of ambiguity between what you store and what's actually in HubSpot, you don't wanna save stuff like deal names. You don't wanna save stuff like in the, the body of engagements that will definitely put you in trouble unless you absolutely need those things.

Speaker 1: (37:17)
Those storing that kind of data makes more sense. If you are doing an app yourself or maybe you're doing an app for your company, if you are doing it for the general public, you do not want that. In addition to if you are saving everyone's data, it is going to rack up and those data costs are going to hit you. And you need to con kind of consider what those costs are going to be, uh, to you, to your app as things, bro. Um, GDPR and hipaa really important here. You, I I cannot stress, um, the importance of being handed some level of notification because so-and-so's data did not get deleted. You want to make sure that you have that automated place in place to destroy people's personal, any kind of p i i you need to be able to get rid of that, uh, essentially playing a game of hot potato.

Speaker 1: (38:11)
Also, we need to really think about high availability and high performance. So generally having one database is not gonna cut it when you're talking about an app for the general public for sure. It will not be the case. If you're talking about, um, dealing with workflow messages, you will probably need to read replicas. You'll probably need some level of caching. Those are things to really kind of strongly consider. And if you don't need those things, then great. Maybe just a single database will do it for you. Maybe just a single, um, MAO database will do it for you that sits somewhere on your company server. But if you, um, really want to stay focused and you don't wanna necessarily have to be a database manager and you don't wanna necessarily have to manage your own re replicas and stuff like that, you'll probably want to look at some cloud things like Amazon r ds or of like, and use those to your advantage to make sure that you have enough redundancy, uh, and scalability in place. That is the end of the decision tree. I'm gonna take a pause right there that actually got the input or we got any questions maybe we can jump into.

Speaker 2: (39:16)
Yeah, I wanted to call out a couple questions. So Martin had a question. Uh, microservices and service and recommendation for hosting these microservices. So just touching on how we, uh, I think the associate is a pretty good example of, uh, leveraging microservices just

Speaker 1: (39:30)
Because, um, okay,

Speaker 2: (39:32)
Volume.

Speaker 1: (39:33)
So microservices does not meaning, um, so list they are strongly probably coupled together, especially in, in, in popular lines of thought. Um, more than likely th there are other ways to go about, uh, microservices than just Lambda. Now, I would easily, um, advocate for Lambda because one, there's a, there, there's a, a cost component that is probably gonna be better than just maybe having a really beefed up e c two instance or compute instance out there. Uh, so there's, there's the cost component to that. Um, I think what I've also seen is a lot of companies especially, so for example, if you're a PhD company and you need to make a a service lambda, then you can probably use P H P with that. Um, but you're probably actually gonna want to do it in like no js cuz no JS is faster. And of course when it comes to, um, serverless lambdas, you pay for the invocation and you also pay for the duration.

Speaker 1: (40:34)
So you want, while you may not necessarily be directly in control of the invocation, you are more of in control of the duration. And while aw w s lambs are definitely cheap, if that's all that you rely on, we will definitely see your cost begin to kind of climb. So you will want to use a technology that gets the duration down as low as humans possible. And in addition to, there's ramp concerns as well. So you wanna use something that's pretty lightweight, pretty quick, gets the job done, and I'll boom done. Uh, we actually, for our, our app associate, uh, we use pretty much node js across the board. Uh, we do have a handful of e c two instances that search for other, for other purposes. But, um, when you are working with, um, workflow stuff, decoupling and cues and Lambda quickly become the name of the game. If it isn't a q maybe it's Kafka or something to that fashion, but, uh, it's pretty easy for me to subscribe. Uh, the usage of a w s I think because a w s is the most mature cloud platform out there. I don't, I would say it's not even really up for dispute. Uh, if you're a bit more cost conscious than, uh, probably Microsoft Azure, um, I would say Google isn't quite there yet. Maybe they're two, three years behind, but AWS is pretty much the way to go, uh, at least for right now.

Speaker 1: (41:52)
What was the, what was the other question there?

Speaker 2: (41:58)
Um, let's touch on the question regarding, I believe, let's see, we had, um, scrolling up through the chat, we had a question regarding kind of, uh, workflows and the positive negatives of consistency there.

Speaker 1: (42:15)
So the, the thing could consider about workflows, um, and if, if you're ever building a workflow app, you're probably gonna hear me say the words, yeah, just do a, just get a lambda and be done with it . Um, because what, what you'll learn is that the workflow engine, let, let's say someone has a workflow and they're going to send 50,000 contacts through that hubs by workflow. And part of that workflow, your app is in that workflow. So your app is going to encounter these 50,000 contacts. You may think that your app is going to encounter 50,000 contacts, one after another, and really rapid succession. That is not the case. Your app isn't going to encounter all 50,000 at the exact same time. It is a massive deluge of information that comes out of the work via, uh, HubSpot Workflow Engine. And so what we have done, um, is we do a few things.

Speaker 1: (43:10)
One, we use, uh, AWS Gateway to help regulate the load that kind of comes in the door. Uh, we also use Lambos and we use EC two instances to basically take in that data and route it to where it needs to go. Uh, we also also leveraged, uh, eight 500 responses to some of our API responses if things start getting hairy. Uh, one thing you will know about most APIs is that, um, if they start banging on your door too hard, e every API is set up to, if they bang on your door too hard, you should give them a response that they can understand. Well then they can say, okay, let me back down a little bit. And for HubSpot, that's a 500 response. So if your, if your Lambdas can't keep up, if your C two instances can't keep up, you need to return a five a hundred response. So that HubSpot says, okay, okay, okay, okay, see you in 72 hours. I think that's the, uh, the time span they work with. And you will, they will resend that message to you again. So you don't necessarily have to deal with data loss, but you definitely need to architect your, your app in a way where being over capacitated is a, is a very expected thing.

Speaker 2: (44:25)
Got another question on, um, from Nicholas in the chat. You, someone that's familiar with hubby b a api Python, he pouts about the server response payroll being a Python class object. Well, this is nice talking my language and how can I use it as, uh, a built-in dictionary and select specific keys inside the many layers of this deck? Uh, multi-dimensional inheritance. So

Speaker 1: (44:48)
We're talking I see that, okay, so if I don't necessarily use Python,

Speaker 2: (44:53)
Well, your dictionary is your, is gonna be like your object for the most part

Speaker 1: (44:56)
Ish. Yeah, but the, the response, oh, you know, maybe you're using the Python sdk. I imagine that's probably, if that's the case, uh, I'm probably gonna have to deflect you and find you someone who does use, uh, if, if using the Python sk, which I imagine in the case, otherwise it's just, we're just talking about API calls. Um, how can I use as a built-in dictionary and then select specific keys inside that is for sure much more of a Python question. My assumption here is gonna gonna be much more general if you have a dump method where you can kind of see the s of some variable, I would dig into that. Um, and then more than likely that variable is gonna have a bunch of properties and methods and see if you can, which one of them are public and if you can call any of them, you'll basically just kind of have to call the ones And, uh, lemme make sure I'm addressing your question here. Have the mini layers of this Yeah. You, you're gonna need to, to, to dump it and kind of see what's going on in that object. I, I don't necessarily, I can't answer the question except you pipeline guy. But, uh, Nicholas, if you wanna ask your email address, try find someone to, to give you a right direct, uh, a right answer there.

Speaker 2: (46:05)
We have one in the qa, um, some love from Michael from which love. So he's talking about kind of, uh, what we call our lab where we have multiple apps and the lab is kind of an external, externally hosted application as well where everything is listed. So Tyler, if you could speak to kind of how that architecture is set up, where we have all of our apps speaking to our old app and the way that the APIs are set

Speaker 1: (46:26)
Up. Yeah, so we have a a a a portal, which is an app. Uh, it's not, it, it basically houses everything. So we basically use ColdFusion and VJs, uh, and MySQL. That's, that's pretty much our primary stack. Uh, but our portal basically allows our customers to log in and then once they log in, they can see there's a, for every app that we, uh, distribute, we have essentially like a baby view JS app that acts like an overview. So if, for example, if you have the ticket portal and you log in, you can see stuff about your ticket portal, you can see here, here's, here's the, all the ticket here, here's what the ticket portal looks like from the outside world. Here are settings about my ticket portal. Uh, some of these things are actually saved to our database. Some of these things are saved to, um, users', HubSpot.

Speaker 1: (47:20)
Um, for example, we have an app called Associate and asso. When you log into our, our, our, our portal, the part you see about associate is a v js app that basically connects directly to our database and just pulls up like a report and pretty much dumps it out to the user. Um, if you have our app, uh, super G or actually clone attack, here we go. Um, CL also gives you a listing page that comes directly from our database. Uh, so what we do is we, we tend to log a lot of our actions, um, for development purposes and for accountability and display purposes kind of keep us, uh, you know, nice and honest. Uh, we tend to try to show people what's going on in the background because a lot of the things in HubSpot, you know, they're API calls, they're, they're really headless. Uh, a lot of customers have no idea what's really going on, but they definitely appreciate when you're actually able to show like, Hey, here's what's actually going on when you're not looking, when you click a button, here are the action that are kind of being taken, or at least here are some of the results that occurred when you took action A, B, or C. Um, but for every app that we build, we basically create another, another baby u j s app and we kinda roll that right into our portal.

Speaker 1: (48:38)
Oh, and, and our portal, um, also manages our, um, subscription management, uh, for the apps. Um, also allows you to kind of manage your HubSpot team in terms of how they interact with our apps. So when we basically built our portal, there were no user permissions, uh, no, not, not the way it is now. Um, and so we still kind of have a handful of things that we're probably gonna transition over fully the HubSpot, but we do some level of management, um, of HubSpot users in the way they interact with our apps in our portal.

Speaker 2: (49:19)
Uh, one thing I would love to touch on, just real quick, I know we're running up on time, is the act, we talk about public a public apps and are they revenue generat? And I know we're leading into kind of the next class where we'll talk a little bit more about the actual limitation of public app. Uh, but HubSpot does now manage the billing by it needs. Um, when someone purchases your public app, you need to be build the, the payment you need to lay up within Stripe or your favorite, you know, you soup, Azure, uh, favorite processes. All of that is managed outside. So you're provisioning if you have charging per user or per advanced user for your app. Uh, like for example, our upcoming, one of our upcoming apps has different levels of users. Users can see things in the CR card and others can actually see a button and click in new actions on that app.

Speaker 2: (50:08)
Uh, but all of that has managed you. So, so when you talk about building a portal, uh, you will need to build some way to transact cause that's completely external. Anything that, there's nothing that is for, for fortune, you know, of good, good faith else, why does not take any percentage of that transaction, nor do they facilitate. So everything is external. So you'll need to at least have some sort of, uh, payment processor and tiering and all of that done yourself for re public ads. So to touch on David's question, uh, it is a little bit complicated. We kind of just threw ourselves into the public act space. Uh, but we did actually start with building something for some somebody, and that was before, it wasn't a publicly available. We had to learn kind of how that this all works. Uh, a few years ago was learning how to interact with the APIs first and foremost. And then once we understood that there was a marketplace, then we kind of backtracked of what we all did. And Tyro, I wouldn't say we, I say Tyrone was the one that kind of brought everything that's actually packaged and commercialized. Lots of trial and error there. And that's kinda what we're gonna talk about in the, the second, the next class and a little bit in the third class as well, how to actually make that package.