Webhooks!

• https://webhooks.fyi/ 
• Webhooks google group
• Railsconf webhooks workshop

[00:00:00] What's up, Colin? How's it going? [00:00:07] Pretty good. Welcome back to build and learn. [00:00:09] We're back. And recording on a Friday this week, I was in Charlotte, for an offsite and yeah, usually we record on Thursdays, but it was an awesome week. I got home insanely late last night. It was like 2am after a bunch of delayed flights and such. but super fun to be in Charlotte. [00:00:27] Have you ever been, out to Charlotte? [00:00:29] I have not, haven't spent much time actually out on the East coast. [00:00:34] I think you would really like it. I think it's like a lot of, your vibe of stuff, like lots of walkable things, lots of biking people, ride this giant rail trail that runs through, the area of town I mostly hang out in is called South end. And it reminds me a lot of Midtown [00:00:52] Reno, tons of like restaurants and, eating outside and just like a million people running around. [00:00:58] And, Having a good [00:01:00] time. It was funny. We went to, a pickle ball, like stadium place where they had like indoor, outdoor, whatever. And while we were there, a run club came in and was getting their beer. It was like the most, like hip, group of young people, [00:01:14] it's a, it's an [00:01:14] activated space. Multi use multimodal mold. Yeah. that's the dream, the 15 minute city. [00:01:22] Yes. It seems a little bit more bike friendly than Reno, just like slightly, but also where there is cars, the cars, I think drive worse and it's a little bit gnarlier, [00:01:33] Yeah. it's tricky cause you have to have, it has to be in your DNA or in your culture. And growing up, Reno had car culture from the get go. literally, motels and roads and everything were designed to get people to motor to Reno. And the idea of us trying to erode away at that and be more bike friendly, it takes, real leadership, which I don't know that Reno has. [00:01:55] I think that they want to check off the checklist. Box, but they don't necessarily know what that means. [00:02:00] And, if you're into the bike stuff, like looking at anything that Paris has done has been insane. Cause that mayor is just like that car, that road is not for cars anymore, just bikes. And they're just like ripping stuff out and they've invested a lot. [00:02:14] but they started really in concert, like during, when they had a lot of stuff closed during COVID. So it's just, Redid so much and now it's very different. obviously like still lots of cars and there's a time and place for it, [00:02:28] it'll be interesting to see how, these cities and towns evolve. Our town is very much, you need a car to get [00:02:33] anywhere. Like everything is super spread out and there's a handful of walking paths here in New Hampshire. But, yeah, most of it is like walking, you're walking on like a road where the speed limit is, 45 or something a lot of times. [00:02:46] So it's gnarly. [00:02:48] So. [00:02:49] yeah, great offsite, great time to connect and hang out and share meals. And, I got to go to the gym one morning with a buddy and, get swole, swole out of control. We went, yeah, [00:03:00] tons of food. so yeah, it was awesome. [00:03:02] and, I'll probably take a weekend or so to recover, but it was fun. what do you got going on [00:03:07] over there? [00:03:08] travel always takes a little bit of a toll, even [00:03:11] if it's fun. So good to [00:03:14] relax for the weekend. what is going on? Mostly just heads down on work, getting ready to move. So really excited to get done with work today. And the weekend is box boxing up stuff and getting ready for moving next week. [00:03:27] Yeah. there's been a thing that I own a domain for that I'm curious. It's like one of those many to do projects that I have on my list. But what I'm curious about, I'm not going to tell you what the domain is quite yet. is what what does your email hygiene look like? do you have multiple personal emails? [00:03:48] Do you have I think a lot of people have this like email address that just accumulates a bunch of stuff and, newsletters and receipts and you buy the one thing from a store and now you get their [00:04:00] emails for life. And sometimes it's Oh, I should. Probably mark this as unsubscribe or mark it as spam, but then you just, you don't. [00:04:07] So then it just keeps gathering more momentum. what does that look like for you? do you have multiple emails? Do you have a burner email? How do you manage that stuff? [00:04:17] I have one burner email that I use when I don't expect to ever actually use the email. I use it more just as an ID to log into random stuff. I have an, a super old personal email address that it's like floating around in some places and it's attached to my Apple ID and I can't figure out how to switch it from my Apple ID. [00:04:37] So it's like one of those super old emails that just forwards into Gmail. to my personal Gmail. And then I have, ajust like admin type email addresses for some of the domains, like wave at cjav. dev is the email address I put on like the YouTube channel and some other things. And so that's like a public facing personal email. And then I have my personal email that, and. [00:05:00] Everything basically dumps into there. That's not work related. And then I go through and aggressively unsubscribe from newsletters and just like crap that comes in with the goal of getting to inbox zero every day. And so there's a handful of newsletters that I'm signed up to that. [00:05:15] I'll only read like one of every four or five of [00:05:18] them. But, they still come in and I'm like, yeah, like sometimes I want to read them. Sometimes I don't. And,if I skip it more than a, five times or something, then I'll usually unsubscribe from the newsletter. but yeah, if it's like crap email coming from, some, SAS product I signed up for just to test it out, three years ago, like that will for sure get unsubscribed. [00:05:41] it's an interesting like social contract where like most websites you sign up with an email and then you somehow get into also receiving like even GitHub, GitHub has a really cool email, like routing system that you can set up. But by default, like you sign up, and it's your way you log in, but it's [00:06:00] also where you get your notifications and then marketing emails, and then you sign up for another site. [00:06:05] system. And now you've got other emails coming in. The newsletter one is tricky for me because I'd like to support some creators and want to follow them. But then, I read like the first 10 that I get and then I start to fall off just so many. And, this makes me want to This makes me miss RSS readers a little bit, which I know still exists, but I don't think a lot of like modern websites are building an RSS feed into their blog and stuff like that, which you should, you definitely should somewhat related to what we're going to talk about today [00:06:38] so yeah, just thinking about it. I am looking at my phone. I have, 65, 000 unread emails. I have a personal email that I just scan it. To see if there's anything important and then I'll mark that page is red. And I don't do anything else with it. And, my personal email has accumulated like plain [00:07:00] ticket confirmations, receipts, newsletters, SAS subscriptions, marketing emails. [00:07:06] Like it is, I think like it's a good test case for, how bad an email inbox can get. So I'm going to play around with some stuff. I have the next week off, which will be moving, but I also, I'm going to play around with some, play around with some little personal ideas just to reset my brain a little bit, that's the chronically online part of me. [00:07:26] But, yeah, stay tuned. We'll talk about it more. [00:07:30] Nice. Yeah. I think for the work side, I tend to make more filters where, okay, I'm going to get these types of notifications from linear every day. And so I don't necessarily want to turn those off, but I do want to categorize them and put them in a place where I can easily mark all of those as red in one spot. [00:07:50] And Yeah. Usually for work email, I'll get more aggressive with filters, but personally emails also. Yeah. It's just a hot mess. [00:07:56] Yeah, I'll have to see if I can find the article. I don't know if it [00:08:00] still holds up. Maybe it's worth doing an updated version on my website, but I use a system where I use, in Gmail specifically, you can set different emojis, like you have the star, but you can also add up to five or six different ones. [00:08:15] And so this might be unhinged like ADHD version of email, but like my inbox. Is more of like a processing place. And so I just mark as red and I don't even, I guess I could archive instead, but I, if I double tap, it turns into an exclamation mark instead of a star. So if you click once, it's the star. I do that if it like needs some sort of action or reply or I need to come back to it. [00:08:41] So it's almost like moving it into a different inbox. If it, if I double tap it, it gets an exclamation mark and it's red. And those are like urgent things. They go to the top. But, Gmail has this multi inbox feature and you can set each inbox to each emoji or each like star thing. so then I have [00:09:00] one that's referenced. [00:09:01] So it's like confirmation emails. hotel confirmations, and then I have one that's scheduled. So it's this is something I want to keep, but I also. Don't need to deal with it right now. And so I, in a way I'm using my email inbox as a to do list, which is like the first rule of email is like, never do that. [00:09:20] but if it's important, it's always in that sidebar. And my goal is to get the sidebar to zero, right? And if it's not something I do with today, I'll move it to scheduled. I think that's, this is where superhuman probably fixes some of this and some of the other like tools that make, Email into more of a to do system or,schedule it. [00:09:43] I use it in a similar way where it is a to do, but it's if it's in, if I leave it unread, then it's a to do if [00:09:49] it, if I, Yeah, like I try to go through and kill everything. I only have one unread right now, [00:09:54] it's, yeah, it's like a little different.but yes, yeah,I should definitely move them out [00:10:00] of like my to do's shouldn't be, my inbox should not be in my to do list for sure. [00:10:05] But [00:10:06] Well, we, I think most people do. So I think, this is a thing that I'm going to play around with. It basically it's the idea I can briefly mention is just that, I want AI to actually be helpful. And this is, feels like an area that. Maybe it doesn't even need to be AI, but computers are very good at this. [00:10:26] So [00:10:27] maybe we can solve this problem and we'll chat about it more. But, I think something that. An app that deals with email could also very well deal with webhooks, and I think we teased this last episode where we've been thinking about what webhooks look like at Discord. We have some forms of webhooks, but you and I have done so many API integrations over the years, and usually webhooks tends to be a way [00:11:00] to integrate with an API in a way that we be notified of something changing. [00:11:05] and so I think today would be great to just dig into webhooks. what are they? I'd be curious if the audience has used them. Love, hate them. if you have a one that you like using, not everybody does them the same. And I think that's a big point of contention is, some companies sometimes think that they can make it better, and break the standard a little bit, but, yeah, what is a whip hook CJ? [00:11:33] For a long time, the way that most people used the internet was just clicking links and reading documents. [00:11:39] And they weren't really like creating anything. They weren't using forms to submit data. and it was. easy for like early people to build websites because it was just HTML and a couple of links to other HTML documents. And if you wanted to change it, you would have to like, just change the code that was, returning the [00:12:00] HTML from the server. And then eventually browsers added support for. forms so that you could fill out,input boxes and text boxes and check boxes, and you could select pull down from select boxes and then click on submit buttons that would send the data from the form to a server somewhere. And the server would then, store. That data as a new document that you could then reference on the internet. And, a lot of us are super familiar with that now. Like it's like the most common paradigm, right? You go to enter a comment on a page, you fill out the form and you click submit. And your comment is sent to some server somewhere and persisted. [00:12:40] The way that I like to think about a web hook is that it is a way for a program to send data to another server and, It uses the same exact underlying mechanics that we would use for submitting a form. So when you click submit on a form on a browser, it's going to send [00:13:00] a post request with some body to a server. And that server is going to parse and interpret the body and do something with it, whether that's just stored in the database or validated or kickoff some. Task a web hook is the same thing, but it's being triggered by a, an application. So it's being triggered by someone else's code. And typically instead of sending, the body of some form, it's sending some data that's in a slightly different format and JSON usually. but it doesn't have to be, it could be XML or whatever. And then the server can use that as, and, store the data or it can use it as a signal to kick off other tasks.so yeah, I, I, think in, Some of the Stripe videos where we explain what webhooks are, we use this analogy of a phone, like a phone system where, if you are a developer. You might create a webhook endpoint and your webhook endpoint is the same thing as like a phone number [00:14:00] that is like a publicly accessible URL, which is the same as a publicly accessible phone number. And you enter that URL into a third party and you say, Hey, when something happens, call me at this. Number or call me at this URL. And so when an event happens in a third party system, you get a notification to that URL. it's like your opportunity to answer the phone and handle a phone call. handle some message from the third party service. And, yeah, it's getting long winded. [00:14:30] So I'm going to stop there, but I think, I could, yeah, rattle on forever about, yeah. My mental model around these. [00:14:36] Yeah. And what was cool about this is that, we used to have to go pull an API, and check, Hey, did anything change? Did anything change? And what I like about that analogy is call me when something changes so that we can not spend all of our time dialing this other phone number to say, is there a new payment in Stripe? [00:14:54] Is there a new email in SendGrid? Is there a new, Literally a new phone call in Twilio. [00:15:00] Twilio itself was probably the one that most popularized webhooks in the early days of webhook land. But I like how you frame it in terms of the building up of we really started off with just get requests on the internet and we, you have to like, think about rest in general. [00:15:14] And we then evolved to posts. And then we eventually were like, Hey, we also need to update stuff. So we need this put. And then we need to delete stuff. So now we have this delete, but with webhooks, you're almost always going to be dealing with posts. Messages that are the call coming in and then processing that, which, is, brings up a whole other thing. [00:15:33] Like, how do we know that it's the right person calling us? How do we know that, we're allowed to answer the phone call and in a secure way? what happens if the phone number is down? What happens if the server is down and we can't pick up the phone and all this other stuff? are there any tools like that you've used? [00:15:49] what do you have any favorite? can like producing companies that, that you like working with integrations that you've done that were like, Oh, this was [00:16:00] easier than I thought. [00:16:02] Obviously I'm a little bit biased towards Stripe and that's the one I have the most experience with, but recently working with Twilio has been pretty nice. but yeah, I was just looking through the stuff we have for craftwork. We are listening for webhooks from deputy, which is our HR tool from Google. From Facebook, from Podium, a messaging platform from SendGrid, our email provider from Slack, from Stripe, from Twilio, from Yelp. So we have like tons of different providers that are sending us these webhook notifications. And, yeah, of those, I think Twilio and Striper, best in breed. the Slack ones are pretty good too. [00:16:39] So,They all generally follow a similar pattern though. Like you set up some URL in our case, we use these namespaced URLs where it's domain slash, inbound webhooks slash, and then the name of the provider. So it'd be like inbound webhooks slash Stripe. And, that's where we can receive these post requests from the third [00:17:00] party. And yeah, different providers will have like different levels of ways to know, did this actually come from the third party or was this a malicious user trying to mark their payment as paid somehow under the hood? but yeah, I don't know. What about you? any others that come to mind about,like ease of use or [00:17:17] Um, I think like Zapier comes to mind in terms of like less the sending of web hooks, but they can, and more of this, like once you get a web hook going into Zapier, like the world is your oyster. Once you get some webhook into Zapier, you can then transform it into some outbound either webhook or API call to go pull the internet together and have it do its bidding. [00:17:41] it's just really amazing to be able, like, how easy is it to send a webhook to Zapier and then have it post to Slack, or post to [00:17:47] Discord, or send you a text. it just really, I like this evented. Model of the internet versus [00:17:55] let me go write some code to go check if anything's new. Okay. We haven't seen that one [00:18:00] before. [00:18:00] Now let's go send it off, to the database or some other place that, that we might send it to. and yeah, so I think like tools like Zapier. I'm sure there's like tools like Glitch and some of these other ones that, that likely have some of this stuff too. I think the more, opinionated stuff, we could talk about, what these are and how to use them, but,what are your go tos for,how you receive them, is it a good idea to, to process them in inline or do you store them and then process them later? [00:18:30] Is there any sorts of like gotchas that you've run into that are like, I really don't like when the webhooks do this or that. how does that look for you? in terms of, do you trust the data that's even coming in the first place? [00:18:42] Yeah, like it depends on the third party, but my ideal flow is that a webhook request comes into your end point. And I like to immediately store the entire payload, like the entire incoming requests in the database [00:19:00] and then kick off a job. And then immediately reply to the provider. I don't want the provider waiting for a response for too long because sometimes that'll cause different things like, maybe it'll timeout or the provider might think that it wasn't delivered. And so They'll start their retry process. And you just like generally don't want to keep the connection open too long. And by saying okay, get the requests, save it in the database, kick off a job, cool. And then later on, I'll do all the processing in a background job for, for the requests that came in. So,every third party will. Almost always have multiple different types of events. So from Stripe, that might be like a payment was paid or a customer was created or a subscription renewed, things like that. And so for each of those different event types, you're going to do different types of work. And I like to route the application logic. [00:19:58] So like what do we, what action do we [00:20:00] actually take depending on the event type? I like to do that routing in a background job. and then sometimes that'll require kicking off different API calls or other longer running tasks. and so having that just isolated in, in, in the background helps a ton because then you can, if needed, you can scale up your background workers. [00:20:18] And it also gives you the nice benefit of If your background job that is handling and processing the webhook fails for whatever reason because of a logic or yeah, most likely because of a logic error in your own code, you can easily build in like retries so you can try to do the thing in the background. If it fails, fix your code, deploy a fix, and then retry those payloads that you already have in your database without having to go to the third party and see if they can resend those same events. [00:20:49] Um, [00:20:50] is pretty unique in that Stripe has an events API so you can go get events. Most it's if you miss it, it's gone. really good web poking [00:21:00] limitations. I think we'll do smart retries and do all this stuff. But what you just said is huge. Cause I think a lot of people are like, Oh, if I don't respond or if I have like a logic error in my code and I'm responding to it in band, it's Then they'll retry if it fails. [00:21:15] It's they're, they are retrying, but then you may also want to retry yourself. Like I like. Respond as fast as possible. Basically you're acting that received the event, save it. And do you then have is it like a webhook router job and then a job for each type of events? Because I could see like payment succeed. [00:21:38] It might be more frequent than payment updated or subscription create or something like that. And so you may even want to scale out specific workers to go more or less, depending on how frequent they are. [00:21:52] it depends on the. Event type. some, sometimes it'll be like, okay,Webhook came in from Slack. [00:22:00] Now we kick off the Slack background job to handle the Slack Webhook notification. And then within the Slack Webhook job, maybe it will, do three different API calls and then do something else. [00:22:12] And depending on the complexity, of each event.I guess it's almost like a command pattern where like each action that you're doing for each event type could be its own class that you're making callable, but I'll also, like most of the time, it's simple enough that I can just write methods in the job itself that, perform the, little bit of like data updates or whatever internally. [00:22:36] So.the one thing I wanted to mention before we go too far though, is that some third parties will expect some type of special response to the web hook notification in order to do something. So a lot of times they're just,like one way pushing notifications to you. So payment was created or payment succeeded, or, Slack, someone, react gene to a [00:23:00] message, but. in the case of Twilio, for example, there are some where the server's response to the webhook needs to be something that Twilio will understand. So for example, if you receive a webhook notification about a call, an incoming call, then they will expect that your Webhook endpoint is responding with TwiML. or, some other response that tells Twilio what to do with that incoming call, whether it should be like routing it or connecting it to a different phone number, or should it start to record it or play back a message or things like that. So there is definitely like this consideration as you're building it out, like how much. Ideally, you can push everything async, but there are cases where some of it needs to be synchronous. yeah, sometimes it ends up being synchronous, but, yeah. in your experience, like how do you typically think about verifying that it came from the right person, like the right third party? [00:23:58] Yeah, this one's tricky because [00:24:00] most providers have you implement their verification method and there are many, in fact, webhooks. fyi is a website from ngrok and they have a webhook directory and they're, Type of like under webhook security. There's a whole bunch of, lists of different types of verification. [00:24:23] including do you have a shared secret? Are you doing HMAC? Are you doing asymmetric keys? Are you doing jot tokens? Are you doing OAuth? there's just so many different things. you also have to think about like replay prevention, and a few other security things, but. You don't really get to have an opinion here. [00:24:42] Like you can not trust the data and do the verification step, get the data, and then make an API call to go get the latest data so that, you have true data, but for the most part, you're going to have to implement the verification step, like with discord, you have to [00:25:00] implement our verification or you're not going to, You have to verify it in order for it to be like successful. [00:25:07] we don't have webhooks today in this type of like notification of a thing that's happened. The way that our webhooks work today are for what we call interaction bots. So if somebody does a slash command. Those can be sent to a webhook, but you have to reply extremely quickly. There's like a bunch of rules around like how many times you can actually reply, I think up to four times, five times so that you can have follow up messages so you could reply to the user instantly when they do the slash command, do some work and then reply. [00:25:39] There's like a window of time. So you can't just reply back in an hour. It has to be within a pretty short period of time. but this is, this whole topic has come up in terms of we do want to build, tell users or developers rather when other things have happened in their app, via webhooks, instead of using, like we use a gateway usually for this, like [00:26:00] a web socket gateway. [00:26:01] But, yeah, there's a bunch of different ones. If you want to check out webhooks. fyi, you can see a pretty good list of well known, developer companies that have included their various things. Some of them are getting called out a little bit for either not having some of the security type stuff. but some of these are hard to build too, as an actual provider, like having zero downtime, rotation, forward compatibility and replay prevention. [00:26:26] Surprisingly, a lot of companies don't have. those things. [00:26:31] There's a lot to implement when you are building the provider side. especially if you're sending like the full payload, right? you mentioned that you might turn around and make a get request. So let's say that some company tells you that something was updated. Oftentimes like the payload of the request will have the updated data about that object. [00:26:54] So maybe. If you are, listening for a [00:27:00] Brex Webhook notification about some, credit card payment that was just made by an employee, you might in the payload of the Webhook request from the third party, have the entire JSON of that payment that was made, or you might just get the ID of the payment that was made from Brex and then have to turn around and make an API call. To say, give me that payment. Give me the latest version of that payment. that kind of gives you a little bit more trust because if a malicious user tried to send you a webhook payload that said, yeah, this payment was made, then any of your, if you just blindly trust and you don't verify that the payload came from the trusted third party, Then you might be, updating your database to say that the payment was created successfully. Whereas if you receive an ID from a malicious third party and then you turn around and try to make a get request to the valid third party with your API [00:28:00] keys, with that ID, either the ID won't exist in that third party, or you'll fetch the actual true source of truth, data from the third party. I don't know if [00:28:09] that makes sense, but, [00:28:11] Yeah. The, webhooks FYI website has best practices. there's a page for best practices for providers and then there's one for consumers too. So like we are trying to talk rest APIs that you over audio. So we know it can be hard to follow, but, really good. I liked the best practices for webhook consumers. [00:28:33] Obviously it requires that the provider offer all of this stuff.the best practices for webhook providers though, I do appreciate the first thing is really good documentation rather provide amazing documentation. security on egress communication, secret keys, encryption, replay prevention, things like that. [00:28:53] So some of these are going to be like above and beyond in terms of I don't think I know many [00:29:00] APIs that have. The ability to, what do they call it? Zero downtime rotation. This is basically the idea that if you ever had to either a web hook payload shape changes, or you have to change out your keys for verification or for a bunch of different things that you may end up receiving. [00:29:22] Events that you can't verify because you've changed your keys. And so you end up with this, do we run two API keys at the same time until all these messages come through? And then once we know that none of the old ones are happening anymore, we shut that down and then now everything's on the new key, there's like a bunch of different ways to handle this. [00:29:41] Usually. Most naive implementations of consuming or producing, do not think about this whatsoever. this is like a champagne problem, of once it's, once you have enough people using and relying on your webhooks, it's a good thing to have because someone's going to run into it when they have to inevitably reset [00:30:00] their keys or just rotate them for security purposes. [00:30:04] it can be particularly tricky if you are,a webhook consumer and the shape of the event changes on the third party. this happens if you can imagine With different AP as different API versions are cut, the shapes of the underlying objects change. So for an old version of an API, maybe it has a property called.description. And for the new version of the API, it's called like description display or something, and so if you, especially if you're running like a webhook consumer that has,really strong. Strongly typed like expectations about the shape of the object coming back. For instance, if you're using like Java or go or something, and it is trying to parse the event. And the event object into a very strict shape, [00:31:00] then you might run into some really wild issues when you're trying to upgrade the API version, because you need to run or be able to handle both different versions of that API payload at the same time. Unless you want to just do like a, cut over where you upgrade your code and then some events fail for some period and then you handle those retries, from the third party. [00:31:21] But yeah, it's, it can get gnarly, with this zero downtime or like attempting to do zero downtime, especially in those like strongly typed languages. Thankfully, Ruby is much, more forgiving and easy to do. Yeah, I think the tricky one there is whether or not you version your webhooks as a provider in addition to your API. It could be the same version or you could have webhook version one, two, three, Or, because those events are pretty important. There's an interesting, I like that they like call this a feature, but it's also like less work, which is just dataless notifications. [00:31:58] So We're just going to tell you the event, but [00:32:00] we're not going to tell you any data and they I mean, this is mostly done for things HIPAA systems will never tell you what the data was because they have to assume that they're emitting these webhooks out into the world and they don't know where they're going. [00:32:13] So they're just going to tell you event. And ID, and maybe like a time and a resource type so that you can go get that resource and follow what is also hopefully a versioned API that's well documented. And now you don't have to worry about response models as much. Like the response model is going to be a little bit more specific to the, like this dataless secure version. [00:32:36] but then you're going to make sure you have to make sure that your API can handle the influx of data. calls to go get that data, right? If you're sending a lot of webhooks, you'd better have good rate limits and a good, API performance to handle All of the incoming calls to just verify and get that data but something to consider that sometimes when you define that webhook URL that volume is [00:33:00] People are going to call you on, you can also define what version, or I guess when you're in Stripe, you can say, I want version, this webhook version to go to this URL. [00:33:08] And I want this webhook version to go to this URL and you can handle them differently, or you can use that. I think web I'm assuming Stripes webhooks also contain the version in them. I think, but not sure actually. [00:33:23] Yeah, that's a good question. but yeah, I guess if you're doing the dataless, version or if you're doing like the dataless approach as a producer and you're just sending the ID and making the consumer go refetch it, that does help a lot with, The versioning issues that you run into. But, I liked that you said your infrastructure has to be ready to handle people making get requests. And what's funny is that I know for sure, I ran into this a lot that, There are people who will take the naive approach and if they get a notification that something happened, they won't just get that one event. They'll go fetch everything. [00:34:00] They'll just go re like,relist every event that's ever happened in re update their database as aggressively as possible. [00:34:07] And That's it's certainly something you got to watch out for. And that comes back to that concept of amazing documentation, really walking people through, best practices and how you expect them to use the API and making sure that it works. it works well for the use cases you want to cover as a producer. [00:34:23] So yeah. [00:34:24] Yes. Yeah. [00:34:26] Webhooks [00:34:27] strong opinions, [00:34:28] yeah, we'll link [00:34:30] and I think the more you use this, like everyone will develop their own, this is how I do webhooks. we, there is a good example if you're into Ruby and Rails, we've talked about a little bit, but, Chris and I did a workshop at, RailsConf, and they've turned it into a Go Rails video that you can watch. [00:34:48] and there's like a sample repo you can follow along with, but it does follow this pattern of catch the webhook, respond quickly, and follows some Rails conventions,[00:35:00] ActionInbox and some of these other things that, so you can see the quote unquote Rails way of handling webhooks. [00:35:05] Mm-Hmm, [00:35:12] In the show notes, you can head over and take a look at the code samples there. And yeah, there's just so much to this too,I don't know. I know that you and I have built a ton of these and it's, it is exciting too when you're like, able to add really nice features that help with automation. [00:35:28] One great example is if you're sending an email out. And someone opens and clicks on links in that email, you can start to display that in your application to show like read receipts and, open rates and click through rates and things like that. You can just build really cool automations based on webhooks. Yeah, lots of fun stuff that you can build with these. [00:35:50] Very cool. you, it looks like you also were playing around. I guess we can put a pin on the web hooks, but encourage people to go and try them out. If you've never [00:36:00] either tried to consume or build a little web hook producer, it's a fun little project to think through all these different things. [00:36:06] but it looks like you've also been playing around with some React native. What's going on over there? Nice. [00:36:10] Oh yeah. Yeah. So for, this little buck, uh, it's like a mint clone that, Colin and I've been working on called buckets. I wanted to learn some more react native. And so I spun up a little mobile app that shows you all the same stuff that you would see on the website. so it's very simple kind of just like list and detail views, but I was really impressed by the react native and expo go developer experience. [00:36:33] I think it's come a really long way and getting set up and. Using it in the simulator and even deploying it to your phone locally. I think maybe within an hour you can go from zero to having something working and, hitting the rails backend with just simple fetch requests inside of react that you would be used to if you've used,made any fetch requests with JavaScript. [00:36:57] And, yeah, it was pretty fun to, to get it up [00:37:00] and running. Yeah, it's definitely, something I hope to do more with,a fun little side quest [00:37:05] Yeah. I gotta get back into that repo and play around with some stuff. I know we still have, I think we got goals merged, but there's a, there's definitely a more advanced version of goals that I miss from when I used to use a bank simple that would let you like, it's a little bit tricky to build an app like mint when you aren't actually a bank because they don't, They only know about the money. [00:37:29] They don't have the money. What was unique about bank [00:37:33] simple was that it was built on top of the bank. And so like, when you have a goal, it could actually move money and hide it from you and move it into the goal and things like that. And I know there's a lot of bank accounts and stuff that have the different, Sub accounts and virtual accounts and stuff like that, but they usually lack those tools of, you can have an auto move 5 every week to this account, but it's not super smart around there's 20, [00:38:00] 20 weeks till this goal. So how much money do I need to put aside each week to hit the goal type of thing? [00:38:06] Yeah. Yeah. The other, I don't know if you saw, I also added like a bunch of chart JS charts, so you can see like pie graphs of like how your buckets, like how your money's broken down into your buckets and also some bar charts of, net worth over time and broken down the composition in each, the accounts for each bucket and stuff like that. [00:38:25] So it's been a fun little spot to mess around and build on. [00:38:28] Yeah, I guess we'll continue to just chip away at that and maybe someday we'll let folks [00:38:34] get [00:38:34] Maybe [00:38:35] but [00:38:37] Cool. [00:38:39] Awesome. Great. Catching up, [00:38:40] Yeah. Good chat. Webhooks. Hopefully, hopefully everyone enjoyed it. And, where can we find notes for the show? [00:38:47] Yeah. Head over to buildandlearn. dev and we'll send some links to resources so you can go check out and build your own webhook, consumers and producers, and, take a look at some of these old. Webhooks, Google [00:39:00] groups and core questions and answers. And, yeah, so hopefully you, enjoyed that episode. [00:39:04] If so, we would love a five star review in your podcast player. Tell a friend who might be hacking around a webhooks and, yeah, if you have questions, hit us up [00:39:15] All right. We'll see you next time. [00:39:18] by friends. [00:39:21] ​ All audio, artwork, episode descriptions and notes are property of CJ Avilla, Colin Loretz, for Build and Learn, and published with permission by Transistor, Inc. Broadcast by