WEBVTT NOTE This file was generated by Descript 00:00:03.055 --> 00:00:04.015 Colin: Welcome to Build and Learn. 00:00:04.015 --> 00:00:04.845 My name is Colin. 00:00:05.200 --> 00:00:07.660 CJ: And I'm CJ and today we're joined by Keith Casey. 00:00:07.660 --> 00:00:13.420 Keith is a product expert at ngrok and has also worked at Okta and Twilio. 00:00:13.630 --> 00:00:17.080 He's all about getting great tech into the hands of awesome people, 00:00:17.080 --> 00:00:21.500 and he lives in Austin and is big participant in the Austin Tech community. 00:00:21.500 --> 00:00:24.990 He also shares thoughts on his blog @ caseysoftware.com. 00:00:25.585 --> 00:00:28.285 He's also co-authored a book about API design. 00:00:28.645 --> 00:00:30.775 And so we're super excited to have Keith here. 00:00:30.775 --> 00:00:34.364 And, we're gonna talk about webhooks today and webhooks.fyi. 00:00:34.384 --> 00:00:37.414 If you haven't seen it, head over and take a look at this knowledge 00:00:37.419 --> 00:00:39.805 base that, ngrok has put together. 00:00:39.955 --> 00:00:44.275 Before we get too deep into it, just wanted to welcome you, Keith, and, 00:00:44.306 --> 00:00:47.262 in case I said anything wrong there, please, feel free to correct the record. 00:00:48.977 --> 00:00:49.847 Keith: No, that was great. 00:00:49.847 --> 00:00:51.827 That, that Keith Casey sounds really impressive. 00:00:51.832 --> 00:00:54.176 I'm not sure how it got to be about me, but, no. 00:00:54.225 --> 00:00:55.245 thanks for having me here, guys. 00:00:55.294 --> 00:00:56.334 looking forward to this chat. 00:00:56.355 --> 00:00:59.385 Colin: As we've been getting into, like looking at who we want to have on the 00:00:59.390 --> 00:01:03.966 show, it seems like the theme so far has been finding people from our past and 00:01:03.966 --> 00:01:05.956 putting them in front of a microphone and. 00:01:05.986 --> 00:01:07.336 Keith is no exception. 00:01:07.336 --> 00:01:12.275 There, sounds like inroads from everything from coworking to Techstars 00:01:12.275 --> 00:01:16.955 to startups that we've used, I think you were dev at Twilio when we like 00:01:16.955 --> 00:01:18.495 met in person for the first time. 00:01:18.544 --> 00:01:21.244 so yeah, getting into some hackathons and things. 00:01:22.014 --> 00:01:25.703 Keith: And I think that's really cool because the people I was meeting 12 00:01:25.703 --> 00:01:28.662 years ago with Twilio, that's when I was there way back in the ancient days. 00:01:29.052 --> 00:01:31.932 The people that were there that were passionate even that they're, even 00:01:31.937 --> 00:01:35.502 if they're the most junior first day on the job, developers after 00:01:35.502 --> 00:01:39.407 that, Applying that passion for 6, 8, 10, 12 years in this case. 00:01:39.707 --> 00:01:42.077 They've moved on to some pretty cool, impressive roles. 00:01:42.146 --> 00:01:45.236 I look around and I'm like, I remember when this guy was writing his first lines 00:01:45.236 --> 00:01:47.036 of code and now he's C T O over here. 00:01:47.306 --> 00:01:52.076 Or I remember when this person just moved to town and now they're a significant 00:01:52.196 --> 00:01:53.816 like impactful community leader. 00:01:54.026 --> 00:01:57.836 And it's awesome to see like friends and allies grow up like that and move 00:01:57.836 --> 00:02:01.136 into their own and see how that passion has affected the world around them. 00:02:01.287 --> 00:02:01.767 CJ: Totally. 00:02:01.767 --> 00:02:05.127 Like just in those 12 years, someone going from writing the first line of 00:02:05.127 --> 00:02:11.378 code to being a cto O as a microcosm tech in itself lets you see a co a full 00:02:11.378 --> 00:02:15.128 career progression over the course of 12 years versus other industries where 00:02:15.128 --> 00:02:18.748 it might take you 40 years or something to kinda climb the corporate ladder. 00:02:19.198 --> 00:02:19.588 Keith: Oh yeah. 00:02:19.617 --> 00:02:19.827 CJ: fun to. 00:02:20.607 --> 00:02:23.837 Keith: when I was first in the field or Twilio way back in the day, we 00:02:23.837 --> 00:02:25.637 had to tell people what an API was. 00:02:26.027 --> 00:02:28.887 We had to teach people like building on APIs was okay. 00:02:28.955 --> 00:02:32.345 AWS had been around for a couple years, but not many people were using it at 00:02:32.345 --> 00:02:35.904 scale, When we think about how fast people's careers have progressed, we 00:02:35.904 --> 00:02:38.963 have to think, that's because part of that is the technology under us 00:02:39.173 --> 00:02:43.583 has moved so quickly and in such radically different directions. 00:02:43.583 --> 00:02:47.123 If you told us 20 years ago, no, most people won't have their own servers. 00:02:47.333 --> 00:02:49.643 They'll be living entirely in this thing called the cloud. 00:02:50.063 --> 00:02:52.283 And the cloud is really just other people's servers. 00:02:52.493 --> 00:02:56.243 But there'll be APIs connecting in all these third parties, like really 00:02:56.243 --> 00:02:57.983 defining and making your app work. 00:02:58.463 --> 00:03:00.413 There's people that would've said, wow, that's cool. 00:03:00.413 --> 00:03:02.283 And there's other people that would've been terrifi. 00:03:02.352 --> 00:03:03.132 The correct answer. 00:03:03.132 --> 00:03:07.131 Somewhere in between those, but that's how see why our careers have progressed the 00:03:07.131 --> 00:03:11.181 way they have, is that everything under us has moved so quickly in interesting ways. 00:03:11.421 --> 00:03:12.741 It's really powerful to see. 00:03:13.476 --> 00:03:13.626 CJ: Yeah. 00:03:13.626 --> 00:03:17.966 I think that's also A fun lens to look at all of these AI changes through that. 00:03:18.015 --> 00:03:22.815 okay, this is an inflection point, and if you are feeling stuck in your ways 00:03:22.815 --> 00:03:26.925 and you're not open to considering new ways of doing things or being agile 00:03:26.925 --> 00:03:29.445 and flexible about what this next year. 00:03:30.220 --> 00:03:32.810 Is going to look like things are going to get wild. 00:03:32.879 --> 00:03:33.329 I don't know. 00:03:33.359 --> 00:03:36.659 I think Colin, you were showing me some stuff with the GitHub co-pilot 00:03:36.659 --> 00:03:39.629 brushes or whatever the other day and I started playing around with 00:03:39.629 --> 00:03:43.410 it and I was really jealous having spent spending most of my time in Vim 00:03:43.440 --> 00:03:45.390 man, these co-pilot brushes in VS. 00:03:45.395 --> 00:03:47.080 Coat are just blowing my mind right now. 00:03:47.149 --> 00:03:51.529 so yeah, it'll be an interesting next decade to see all of the progress that 00:03:51.529 --> 00:03:56.599 happens within tech and our careers and those folks that are getting into AI for. 00:03:57.484 --> 00:03:57.749 Colin: Yeah. 00:03:58.674 --> 00:04:01.164 And that's a great segue to talk about what we're talking 00:04:01.164 --> 00:04:02.764 about today, which is webhooks. 00:04:02.813 --> 00:04:07.403 I was actually digging into kind of what made webhooks popular, and you might 00:04:07.403 --> 00:04:08.763 be able to shed some light on this too. 00:04:08.793 --> 00:04:11.073 the idea that when you're at Twilio, you weren't just trying 00:04:11.078 --> 00:04:14.283 to get people to use Twilio's api, you were trying to teach them how. 00:04:14.818 --> 00:04:18.968 why they even wanted to use an API in the first place, or what an API even is. 00:04:18.999 --> 00:04:24.006 and just to set the stage, we found like the earliest mentions of webhooks was from 00:04:24.006 --> 00:04:26.607 Jeff Lindsay, all the way back in 2006. 00:04:27.057 --> 00:04:31.491 And the idea that thinking of a world today where webhooks are available on 00:04:31.491 --> 00:04:35.901 almost every app, but there was a point at which there, there were no webhooks. 00:04:36.281 --> 00:04:37.731 And there were no APIs. 00:04:37.802 --> 00:04:39.781 today we're gonna be talking about webhooks and specifically 00:04:39.781 --> 00:04:43.701 this webhooks.fyi site that you guys have built at ngrok. 00:04:43.792 --> 00:04:47.452 what have you guys seen as far as like the rise of webhooks? 00:04:47.452 --> 00:04:48.862 Popularization of webhooks? 00:04:49.025 --> 00:04:49.835 Keith: Yeah, absolutely. 00:04:49.835 --> 00:04:52.604 So I mean you call it, Jeff Lindsay was one of the first people to 00:04:52.814 --> 00:04:54.504 put the word together a webhooks. 00:04:54.524 --> 00:04:56.355 And at that point it was actually two words. 00:04:56.383 --> 00:04:57.713 just a bit of trivia for you there. 00:04:57.783 --> 00:05:00.933 but in 2006 and seven, he was out there talking about this. 00:05:01.233 --> 00:05:04.413 And fundamentally he went back to the, some of the earliest principles 00:05:04.503 --> 00:05:08.123 in object-oriented design and the sort of the encapsulation 00:05:08.128 --> 00:05:09.283 model of object oriented design. 00:05:09.283 --> 00:05:14.181 Cause remember, when you're building object, To rewind back to, CS 1 0 1 00:05:14.181 --> 00:05:18.161 and you've got this object, you really don't want to expose the internals 00:05:18.161 --> 00:05:21.761 of how that works because now you get tied into the specifics, the, 00:05:21.791 --> 00:05:23.651 you get into all the idiosyncrasies. 00:05:23.651 --> 00:05:25.781 You now have to worry about that state of the object. 00:05:26.001 --> 00:05:27.801 There's a concept called message passing. 00:05:28.491 --> 00:05:32.001 And message passing is just the state of this thing has changed. 00:05:32.181 --> 00:05:33.051 Here's how it's. 00:05:34.346 --> 00:05:34.671 that's it. 00:05:34.881 --> 00:05:38.791 That's, that goes all the way back to, small talk in the sixties and seventies, 00:05:39.151 --> 00:05:41.341 and it's a exceptionally powerful concept. 00:05:41.821 --> 00:05:44.011 Now when you're talking about individual components within a 00:05:44.016 --> 00:05:45.931 system, that works out really well. 00:05:46.141 --> 00:05:49.441 When you then say, okay, we're gonna take those components instead of 00:05:49.446 --> 00:05:52.861 operating the same memory space where we could just pass things over a bus 00:05:52.861 --> 00:05:54.151 or a port or something like that. 00:05:54.451 --> 00:05:56.671 Let's put them thousands of miles. 00:05:57.781 --> 00:06:01.060 In different architectures, in different data centers, with all 00:06:01.060 --> 00:06:04.270 kinds of things in between them, we now have to figure out how in the 00:06:04.270 --> 00:06:05.680 world do they do message passing? 00:06:06.040 --> 00:06:08.500 And it turns out webhooks was the model to do that. 00:06:08.620 --> 00:06:12.951 And simply it's, it's JSON over HTTP or XML over HTTP. 00:06:13.421 --> 00:06:16.931 It conceptually, when you realize, oh wait a minute, it's this concept 00:06:16.931 --> 00:06:18.641 that's now close to 60 years. 00:06:19.861 --> 00:06:21.956 just updated for the tech stack we're working on. 00:06:22.376 --> 00:06:26.604 It's cool to think about, like we've never gotten away from those core principles. 00:06:26.634 --> 00:06:29.604 We've just applied them to the medium that we're working in, and 00:06:29.674 --> 00:06:32.984 He, Jeff Lindsay was started talking about webhooks2006 and seven. 00:06:33.034 --> 00:06:36.004 he joined a little company called Twilio not too long after that. 00:06:36.364 --> 00:06:39.874 And basically Jeff Lawson, the CEO of Twilio, went to Jeff Lindsay 00:06:39.874 --> 00:06:41.434 and said, I like what you're doing. 00:06:42.124 --> 00:06:44.884 We have some problems that I think that's a solution. 00:06:44.889 --> 00:06:45.664 Let's blend this. 00:06:45.664 --> 00:06:46.594 Let's pull this in. 00:06:47.014 --> 00:06:49.804 And so I attribute a lot of the early webhooks, one to 00:06:49.804 --> 00:06:51.424 Jeff and the other to Jeff. 00:06:52.264 --> 00:06:55.774 So Jeff Lindsay brought to Jeff Lawson and they made it work in Twilio and. 00:06:56.269 --> 00:06:57.888 Frankly we are blessed at Twilio. 00:06:58.158 --> 00:07:01.758 We were one of the first people into that space to do it at scale and we were 00:07:01.758 --> 00:07:03.768 admired for a lot of different things. 00:07:04.158 --> 00:07:08.088 And one of the things was the model behind those webhooks, cuz fundamentally it's 00:07:08.268 --> 00:07:12.288 this thing, this text message, this phone call, this recording has changed state. 00:07:13.473 --> 00:07:16.773 Being able to pass that message across a wire, regardless of your tech stack 00:07:17.163 --> 00:07:19.143 ended up being exceptionally powerful. 00:07:19.653 --> 00:07:25.042 Then when you take the macro trend of, uh, AWS, of GCP, of all these things coming 00:07:25.042 --> 00:07:28.822 in the market, and you go, wait a minute, my tech stack is no longer a stack. 00:07:29.302 --> 00:07:32.362 It's a bunch of stacks sitting in a bunch of different places, and 00:07:32.362 --> 00:07:35.482 oh, by the way, it has dependencies on apps that I'm building. 00:07:35.542 --> 00:07:37.582 Has dependencies on apps that you are building, has 00:07:37.582 --> 00:07:38.692 dependencies on third parties. 00:07:40.087 --> 00:07:42.457 WebBook is the only way to do that reasonably. 00:07:42.637 --> 00:07:45.907 There are other approaches, but when you say, Hey, look, I don't care 00:07:45.907 --> 00:07:48.997 about the tech stack, I don't care about your architecture, I don't 00:07:48.997 --> 00:07:54.007 care about anything else other than are you speaking JSON over HTTP. 00:07:54.817 --> 00:07:56.167 That makes life really easy. 00:07:58.457 --> 00:07:58.692 CJ: Totally. 00:07:58.692 --> 00:08:03.012 And I think also like when you think about a normal web framework and you're building 00:08:03.012 --> 00:08:07.851 out these typical features, whether it's, the classic, you're just taking the post 00:08:07.851 --> 00:08:10.131 body from a form and submitting that to. 00:08:10.281 --> 00:08:14.001 Some endpoint, or if you're taking the post body of that form and using 00:08:14.001 --> 00:08:17.941 JavaScript with, fetch or Ajax or whatever to submit that as j s o to a 00:08:17.941 --> 00:08:23.950 server endpoint, you can build your web application and your web hook handler 00:08:24.070 --> 00:08:27.250 using all of the same tools under the hood, which I think is also pretty 00:08:27.255 --> 00:08:31.049 killer because yes, there are these other solutions that, you might be using. 00:08:31.119 --> 00:08:35.829 some message queuing system or some other sidecar thing that happens to 00:08:35.829 --> 00:08:40.269 reach into your database, but it becomes much, much easier to reason about, in my 00:08:40.269 --> 00:08:44.258 opinion, your web hook handlers if they're following the same patterns that your, the 00:08:44.258 --> 00:08:45.938 rest of your web application is following. 00:08:45.938 --> 00:08:48.929 And yeah, I, it's, I don't know, it's it's interesting to see how. 00:08:48.998 --> 00:08:54.158 the trend in industry has landed on or decided that JSON over 00:08:54.158 --> 00:08:56.448 HTTP is the end all be all. 00:08:56.868 --> 00:08:59.926 And I think it's a lot of it is because like we don't really have 00:08:59.926 --> 00:09:05.066 another pattern that has emerged for just typical web development that is 00:09:05.096 --> 00:09:07.976 significantly better and, something that we might all want to migrate to. 00:09:08.044 --> 00:09:09.664 and so yeah, at Stripe we. 00:09:10.729 --> 00:09:15.129 Looked very closely at our web hook solution and thought about oh, what 00:09:15.129 --> 00:09:18.339 if we changed it to all of these other different potential things? 00:09:18.339 --> 00:09:20.639 Then, would people still adopt it? 00:09:20.639 --> 00:09:25.241 It's okay, 99.9% of people building on the web or building mobile applications 00:09:25.246 --> 00:09:29.171 or whatever, are going to still use webhooks because of the way that they're 00:09:29.171 --> 00:09:30.411 set up and the way that they work. 00:09:30.479 --> 00:09:33.294 Keith: Yeah, all of us know, and we have a favorite HTTP tool. 00:09:33.534 --> 00:09:35.814 All of us know we have a favorite JSON tool. 00:09:36.324 --> 00:09:39.114 When that's the baseline you're starting from, it's hard to get 00:09:39.114 --> 00:09:40.264 people to move to anything else. 00:09:40.334 --> 00:09:41.583 and I appreciate that. 00:09:41.583 --> 00:09:42.393 I appreciate that. 00:09:42.393 --> 00:09:45.753 It's hard right now because we can work with tools we're familiar with. 00:09:45.843 --> 00:09:48.804 We don't have to introduce new patterns, new technologies or god 00:09:48.804 --> 00:09:53.544 forbid, a vendor specific protocol that's we're done with those hopefully. 00:09:53.649 --> 00:09:57.859 Colin: Speaking of tools, can you give us kind of the high level of what ngrok 00:09:57.879 --> 00:10:01.358 is trying to solve as a company, and as the kinds of tools that you guys 00:10:01.388 --> 00:10:05.298 are working on, and what inspired the creation of webhooks.fyi, what were you 00:10:05.298 --> 00:10:09.648 guys seeing as far as these simple tools being used in really powerful ways? 00:10:10.668 --> 00:10:11.328 Keith: Yeah, absolutely. 00:10:11.398 --> 00:10:13.478 Ngrok, founder and CEO is Alan Shreeve. 00:10:13.478 --> 00:10:15.848 He was employee number six or seven at Twilio. 00:10:16.058 --> 00:10:19.568 If you send an SMS using Twilio, you probably used his code at some point. 00:10:20.018 --> 00:10:23.468 But while he is working with those webhooks, way back in the day, he ran 00:10:23.468 --> 00:10:26.558 into this very simple thing of when you pull out his phone and send a text. 00:10:27.273 --> 00:10:29.433 he'd wanna route that to the app he was building locally. 00:10:29.853 --> 00:10:32.043 And there are a couple other alternatives at that point. 00:10:32.043 --> 00:10:32.673 And he said, you know what? 00:10:32.673 --> 00:10:35.073 I wanna learn, go and I wanna figure this out. 00:10:35.343 --> 00:10:38.403 So he wrote the first version of ngrok basically to do 00:10:38.403 --> 00:10:39.963 that, to scratch his own itch. 00:10:40.353 --> 00:10:44.062 And then he started adding things like, request capture and replay to be 00:10:44.062 --> 00:10:45.472 able to say, I've got this web hook. 00:10:45.472 --> 00:10:48.592 It came in successfully instead of having to pick up my phone again. 00:10:49.072 --> 00:10:51.142 Let me just replay that. 00:10:52.117 --> 00:10:52.392 . Awesome. 00:10:52.422 --> 00:10:53.512 That was really cool. 00:10:53.542 --> 00:10:56.752 And most people find ngrok through some of those webhooks because if you 00:10:56.752 --> 00:11:00.201 look at any web hook guide out there, odds are step one of integrating 00:11:00.206 --> 00:11:04.651 with stripes webhooksis probably go install inro, which is awesome. 00:11:04.651 --> 00:11:08.041 fundamentally what ngrok is, it's a platform for providing 00:11:08.041 --> 00:11:09.691 secure connectivity into any. 00:11:10.846 --> 00:11:13.636 So today we're talking about webhooksand local development. 00:11:13.726 --> 00:11:16.156 It can also be IOT devices on a customer site. 00:11:16.366 --> 00:11:19.316 It can be a Kubernetes cluster sitting inside your data center. 00:11:19.366 --> 00:11:23.296 it could be the deep in the bowels of that ancient D data center, getting 00:11:23.296 --> 00:11:25.046 access to the database behind the scenes. 00:11:25.075 --> 00:11:29.124 CJ: we're assuming that you, dear your listener, know what a web hook is 00:11:29.549 --> 00:11:30.179 Keith: Oh, yeah. 00:11:30.624 --> 00:11:31.554 CJ: we'll just gloss over. 00:11:31.584 --> 00:11:34.374 I think it's fine if we gloss over it because we want people to go 00:11:34.374 --> 00:11:38.344 read webhooks.fyi, which is gonna teach you all about webhooksand 00:11:38.574 --> 00:11:40.393 what they are and and how they work. 00:11:40.398 --> 00:11:44.124 But I think it's worth at least explaining the fundamental issue with 00:11:44.124 --> 00:11:49.374 like why that request was not delivered to the local running application and 00:11:49.444 --> 00:11:50.314 Keith: Yeah. 00:11:50.404 --> 00:11:50.734 Yeah. 00:11:50.734 --> 00:11:55.353 So when you get, when you're working with Stripe, Twilio, slack, whatever, 00:11:55.593 --> 00:11:59.104 when the change in state happens, a payment being processed as text 00:11:59.104 --> 00:12:02.513 message being received, a new slack message coming across, that web hook, 00:12:02.543 --> 00:12:03.983 that payload has to go somewhere. 00:12:03.983 --> 00:12:06.983 So the web hook is just telling you the change in state has happened. 00:12:06.983 --> 00:12:08.033 Here's some information. 00:12:08.748 --> 00:12:12.408 And so when you're running in your local environment, there's DNS issues, there 00:12:12.408 --> 00:12:16.168 are SSL issues, there's all these things to get from your local environment. 00:12:16.218 --> 00:12:18.568 getting from your local environment out is super easy. 00:12:18.599 --> 00:12:20.249 that's what our browsers do every day. 00:12:20.519 --> 00:12:26.818 Getting in is a horrifying complexity of dns, of ssl, of na traversal, 00:12:26.818 --> 00:12:27.928 of all these different things. 00:12:28.318 --> 00:12:29.738 And so what Ingra does is it opens a. 00:12:29.807 --> 00:12:32.057 over 4 43 outbound to our cloud. 00:12:32.357 --> 00:12:36.497 And then the cloud handles a, generates a URL that then that web 00:12:36.497 --> 00:12:39.617 hook can call into that then gets routed down into your machine, 00:12:40.707 --> 00:12:40.947 CJ: Yeah. 00:12:40.947 --> 00:12:44.469 So it's if you are running your app locally, if you're building a web 00:12:44.469 --> 00:12:47.889 application locally and you're running it and it pops up on local host 3000, 00:12:48.249 --> 00:12:52.479 like your friend that's in a different city cannot go to local host 3000 and 00:12:52.479 --> 00:12:56.649 see your program running because it doesn't have access to the internet. 00:12:56.649 --> 00:12:59.989 And I think it's also probably worth mentioning that It's hard to get 00:12:59.989 --> 00:13:01.879 into someone's computer on purpose. 00:13:02.179 --> 00:13:04.909 , like the operating systems are protecting us. 00:13:04.909 --> 00:13:09.019 Yeah, it should be really hard for any outside service to get in and 00:13:09.050 --> 00:13:13.160 this is intentionally difficult and yeah, luckily anytime we're 00:13:13.160 --> 00:13:14.390 working with third parties, we can. 00:13:15.050 --> 00:13:20.000 Depend on ngrok to poke a hole through that magical firewall that 00:13:20.000 --> 00:13:22.310 we've created and give access. 00:13:22.340 --> 00:13:25.039 I, is there any like security considerations, I guess this is of 00:13:25.039 --> 00:13:29.239 like tangential, but that people should be aware of when running 00:13:29.239 --> 00:13:32.610 ngrok because you are poking a hole in that, yeah, in that inbound 00:13:33.195 --> 00:13:33.525 Keith: Yes. 00:13:33.525 --> 00:13:36.705 Poking a hole is a phrase that comes up pretty often because 00:13:36.773 --> 00:13:38.133 at first glance, it's scary. 00:13:38.164 --> 00:13:40.304 it's scary cuz you're like, wait a minute, I'm doing what? 00:13:40.328 --> 00:13:44.353 so what we did a few, about a year or so ago now, we launched, or we had them for 00:13:44.358 --> 00:13:45.763 a while, but we doubled down all of them. 00:13:46.003 --> 00:13:49.033 We've got some capabilities you can put on top of that tunnel 00:13:49.033 --> 00:13:50.683 so you can do IP restrictions. 00:13:50.893 --> 00:13:53.383 So if you've got IOT devices, you can say only our command and 00:13:53.383 --> 00:13:55.093 control server has access to it. 00:13:55.573 --> 00:13:57.393 You've got, mutual t. 00:13:57.548 --> 00:14:00.308 So you can have shared certificates on each side and a handshake 00:14:00.313 --> 00:14:01.428 to secure that connection. 00:14:01.457 --> 00:14:05.747 you can also put an identity provider in front if you do dash OAuth equals Google. 00:14:05.957 --> 00:14:08.687 Now you can force someone to log in through Google before they 00:14:08.692 --> 00:14:09.947 have access to your connection. 00:14:10.667 --> 00:14:12.767 And in fact, you can add restrictions on top of that. 00:14:12.857 --> 00:14:16.191 In fact, let's see, by the time this airs, we added some updates to our 00:14:16.191 --> 00:14:18.441 free plan to be able to add OAuth. 00:14:18.561 --> 00:14:21.411 So you've got very simple OAuth protections built into the free plan 00:14:21.416 --> 00:14:23.391 itself, along with web hook verification. 00:14:23.901 --> 00:14:26.566 So before you let any traffic into that connection. 00:14:26.806 --> 00:14:30.916 We ngrok in the cloud can verify that payload is from stripe, from 00:14:30.916 --> 00:14:32.836 Twilio, from Slack, whatever. 00:14:33.046 --> 00:14:35.836 And then anything that it can't verify gets. 00:14:36.916 --> 00:14:38.326 and it never makes it to your server. 00:14:38.686 --> 00:14:42.436 So yes, it is poking a hole, but yes, we can layer on a variety 00:14:42.436 --> 00:14:43.436 of security, policies on top. 00:14:44.606 --> 00:14:44.936 Colin: Nice. 00:14:44.936 --> 00:14:45.686 We're poking a safe. 00:14:46.331 --> 00:14:46.661 CJ: Yeah. 00:14:48.866 --> 00:14:51.896 Colin: There's a, these are your taglines that you can have these for free, Keith, 00:14:51.926 --> 00:14:52.166 so 00:14:52.351 --> 00:14:52.856 Keith: a safe hole. 00:14:52.856 --> 00:14:53.216 Thank you. 00:14:53.426 --> 00:14:53.796 Thank you. 00:14:53.867 --> 00:14:55.896 I appreciate the the spirit it was offered in. 00:14:55.896 --> 00:14:56.376 How's that? 00:14:56.751 --> 00:14:57.591 Colin: Absolutely. 00:14:57.711 --> 00:14:57.951 Yeah. 00:14:57.951 --> 00:15:01.901 And I what's exciting to me, webhookshave always fascinated me because I, when 00:15:01.901 --> 00:15:06.371 I teach APIs, I like to think of it as like turning a light bulb on across 00:15:06.371 --> 00:15:08.451 the world and like a web hook is a. 00:15:08.696 --> 00:15:12.546 A post request to a thing and hue lights and other things. 00:15:12.574 --> 00:15:15.224 you can have a web hook that, when a payment goes through Stripe, 00:15:15.614 --> 00:15:17.084 make this light flash green. 00:15:17.114 --> 00:15:21.532 Or play, your cash register sound in, in Slack, which is fun. 00:15:21.537 --> 00:15:25.282 And there's a lot of ways, like Zapier today is one of the bigger, 00:15:25.351 --> 00:15:28.531 Low-code integrate X to Y type of apps. 00:15:28.531 --> 00:15:31.231 And most of that today is run by webhooks. 00:15:31.231 --> 00:15:35.180 So you may, if you're new to webhooks, you may be using them already. 00:15:35.180 --> 00:15:37.568 You're just not, catching and sending them yourself. 00:15:37.618 --> 00:15:40.738 things like lambda functions in the API gateway and aws, like a 00:15:40.743 --> 00:15:43.907 lot of that is really powering webhooks, which is really great. 00:15:43.938 --> 00:15:45.508 and I think that there's two sides of this, right? 00:15:45.518 --> 00:15:50.438 If you're a company or an app and you wanna provide webhooks to an 00:15:50.438 --> 00:15:55.838 end user, or if you're more commonly your a developer who wants to consume 00:15:55.838 --> 00:15:58.908 webhooks like stripe, webhooks, slack, webhooks, things like that. 00:15:58.978 --> 00:16:03.837 what did some of that inspire, what webhooks.fyi is built for, or how 00:16:03.837 --> 00:16:05.247 did that come about for you guys? 00:16:05.357 --> 00:16:07.247 Keith: Y Yeah, it completely inspired it. 00:16:07.277 --> 00:16:10.886 When we were working on the web hook verification within ngrok, one of the 00:16:10.891 --> 00:16:13.856 first things I was tasked with when I joined up was, find a list of all the 00:16:13.856 --> 00:16:16.266 webhooks out there and let's figure out which ones we're gonna support. 00:16:16.296 --> 00:16:17.886 it's a very reasonable request. 00:16:17.886 --> 00:16:22.986 So I googled, web hook directory and web hook, like best practices and everything. 00:16:23.196 --> 00:16:25.146 And it turns out there wasn't much out there. 00:16:26.046 --> 00:16:28.191 Everyone had their list of their favorites, but no one 00:16:28.191 --> 00:16:31.641 actually dug into how are these verifications actually handled. 00:16:32.001 --> 00:16:36.501 So I was sitting there making a Google doc of, 50, end up with like a hundred 00:16:36.501 --> 00:16:38.161 and some different webhooks of. 00:16:39.076 --> 00:16:41.491 API company you can think of was probably on that list. 00:16:41.521 --> 00:16:44.350 I think that list has grown to 150 or so at this point. 00:16:44.419 --> 00:16:47.458 and we are looking at how do you verify the payload, which ones support 00:16:47.458 --> 00:16:50.909 ssl, which ones don't, what are the payload options for each of those? 00:16:51.179 --> 00:16:54.299 And while we are building our own implementation of that verification, 00:16:54.629 --> 00:16:58.899 we realize, like realized like there was no directory, there wasn't a 00:16:58.904 --> 00:17:00.959 place for capturing this information. 00:17:01.229 --> 00:17:03.059 And I'm sitting there with this big Google Doc, I'm like, 00:17:03.059 --> 00:17:04.319 why don't we turn this into a. 00:17:05.394 --> 00:17:06.569 and just share it with people. 00:17:06.809 --> 00:17:10.619 And then we started digging into what are some of the best practices around this. 00:17:10.949 --> 00:17:14.639 So we first analyzed, we, we took the top a hundred or so and put them on 00:17:14.639 --> 00:17:18.988 the site and we said, okay, how are the different web hook providers, what 00:17:18.993 --> 00:17:20.678 verification methods do they offer? 00:17:20.702 --> 00:17:25.207 some are HMAC 256, some are this, some are that, we dug into, which 00:17:25.207 --> 00:17:27.187 ones are over HTTP versus HTTPS. 00:17:27.427 --> 00:17:30.817 And we dug through probably 10 or 12 different aspects of all of. 00:17:32.107 --> 00:17:32.947 And we released it. 00:17:33.547 --> 00:17:37.897 And we released, here's what we see in the wild in the field right now. 00:17:38.017 --> 00:17:40.477 Here's what we all know are good things. 00:17:40.687 --> 00:17:44.336 Let's make a list of the ideal and call out and celebrate the 00:17:44.336 --> 00:17:45.416 people who are doing it well. 00:17:45.716 --> 00:17:51.266 And so on the site, webhooks.fyi, there's a web hook directory and 00:17:51.266 --> 00:17:55.376 there's a bunch of list of web hook providers and some that have red X's 00:17:55.376 --> 00:17:56.816 and some that have green check marks. 00:17:57.193 --> 00:17:58.843 And we're trying to encourage people to do things. 00:17:59.318 --> 00:18:00.378 CJ: this is a fun list. 00:18:00.447 --> 00:18:04.507 and also, there's people that are not on this list that I'm like, oh, 00:18:04.535 --> 00:18:08.075 I wonder if that would encourage them to migrate from pub sub hubub to 00:18:08.105 --> 00:18:10.124 webhooks or some, something similar. 00:18:10.124 --> 00:18:13.714 But, I think also it's worth talking and breaking down a little bit. 00:18:14.524 --> 00:18:17.044 Some of those characteristics that you went through. 00:18:17.314 --> 00:18:22.844 So do they support, TLS or how are they verifying signatures or 00:18:23.204 --> 00:18:27.403 payloads or just, what are of the differences there and maybe, yeah. 00:18:27.403 --> 00:18:30.283 Do you have any that are like the gold standard that like, oh 00:18:30.283 --> 00:18:32.893 hey, everyone should go implement their webhooks, like this company. 00:18:33.793 --> 00:18:34.063 Keith: Yeah. 00:18:34.093 --> 00:18:36.704 that was the fun thing is we had this list of a hundred and some different 00:18:36.704 --> 00:18:40.103 webhook providers and we categorized all of them and we said, okay, which 00:18:40.103 --> 00:18:41.543 of the ones we should implement first? 00:18:41.603 --> 00:18:43.553 We narrowed, did the list down to about 50. 00:18:43.823 --> 00:18:46.433 Then we said, okay, now let's actually start building the 00:18:46.433 --> 00:18:48.973 verification code to verify these 50. 00:18:49.883 --> 00:18:53.333 So you guys wanna take a guess of how many different verification 00:18:53.333 --> 00:18:55.403 processes there were for 50 web. 00:18:55.812 --> 00:18:56.122 Colin: Probably 50 00:18:56.223 --> 00:18:57.103 Keith: 50. 00:18:57.132 --> 00:18:59.682 CJ: yeah, I think, I'm going to cheat here a little bit 00:18:59.682 --> 00:19:02.712 and guess like 10 based on the 00:19:02.727 --> 00:19:07.107 Keith: there were 49, 49 different approaches. 00:19:07.112 --> 00:19:10.608 There was one, I forget who it was offhand, but there was one that 00:19:10.608 --> 00:19:12.118 duplicated somebody else and that was it. 00:19:12.188 --> 00:19:12.938 it was horrifying. 00:19:13.223 --> 00:19:14.933 Colin: It's what happens when you roll your own auth, 00:19:15.043 --> 00:19:16.013 CJ: Holy smokes. 00:19:16.968 --> 00:19:17.243 Keith: Yeah. 00:19:17.303 --> 00:19:17.513 Yeah. 00:19:17.543 --> 00:19:20.093 and this is just the authentication. 00:19:20.093 --> 00:19:21.473 This is just a verification. 00:19:21.478 --> 00:19:23.283 This isn't the additional capabilities. 00:19:23.352 --> 00:19:25.542 but when we look at some of those capabilities, we have 00:19:25.542 --> 00:19:27.122 things like, Shared secrets. 00:19:27.452 --> 00:19:29.633 So this is the model that, let's see. 00:19:29.633 --> 00:19:32.362 I think Okta uses it, DocuSign. 00:19:32.362 --> 00:19:33.562 Oh, Twilio implements this too. 00:19:33.682 --> 00:19:37.072 In the dashboard itself, there'll be some sort of secret that's generated and then 00:19:37.072 --> 00:19:39.772 that gets used in the signature creation. 00:19:40.142 --> 00:19:44.562 And then on the receiver side, you've got that secret and then you generate 00:19:44.567 --> 00:19:48.802 the same hash and you use that secret to make sure, yes, this was definitely came. 00:19:49.852 --> 00:19:51.742 Twilio, this definitively came from Okta. 00:19:52.792 --> 00:19:58.102 What we've seen a lot of in the wild is people not verifying payloads at all. 00:19:58.912 --> 00:20:02.181 In fact, I do a demo where I open a very simple Twilio app 00:20:02.181 --> 00:20:03.231 and I have people texting in. 00:20:03.231 --> 00:20:07.671 I go, Hey, by the way, if you have Postman, there's my u URL 00:20:07.676 --> 00:20:09.201 endpoint on the board right now. 00:20:09.681 --> 00:20:11.431 Why don't you go ahead and do a post and see what happens? 00:20:11.501 --> 00:20:15.306 and people start posting, data to my endpoint right there on the screen. 00:20:15.546 --> 00:20:18.006 And sometimes things go off the rails. 00:20:18.246 --> 00:20:22.156 It will keep it pg, pg rated here, but sometimes it goes off the rails. 00:20:22.181 --> 00:20:25.397 and I point out to people, I say, look, this is a silly Twilio 00:20:25.397 --> 00:20:26.867 app in front of an audience. 00:20:27.077 --> 00:20:30.557 I said, what if you are waiting for a Stripe web hook to confirm, 00:20:30.677 --> 00:20:33.267 yes, Colin paid for this shopping. 00:20:33.296 --> 00:20:36.777 if I know your endpoint and you haven't verified that payment did come, or 00:20:36.777 --> 00:20:40.377 that payment notification came from Stripe, somebody else could make a 00:20:40.382 --> 00:20:43.137 post and Mark Collins' order is paid. 00:20:43.857 --> 00:20:44.907 And how would you know that? 00:20:45.327 --> 00:20:47.067 How would you ever find that out? 00:20:48.987 --> 00:20:49.737 And that's. 00:20:50.637 --> 00:20:51.237 It's scary. 00:20:51.627 --> 00:20:55.266 So anyway, we go through these different processes and we wanna encourage 00:20:55.266 --> 00:20:58.686 people to verify whether that is a shared secret, like a Twilio or Okta. 00:20:58.866 --> 00:21:01.008 There's some that use, like asymmetric keys. 00:21:01.013 --> 00:21:03.768 I think SendGrid and PayPal use those. 00:21:04.128 --> 00:21:07.137 So you've got a, a key on each side, and then it signs with the private. 00:21:07.812 --> 00:21:09.792 And you can verify it with the public key and say, yes, 00:21:09.792 --> 00:21:11.992 definitively this came from PayPal. 00:21:12.060 --> 00:21:17.290 some of 'em are using like is a whole other challenge, but it's a, 00:21:17.290 --> 00:21:20.590 it's still, it comes down to, it's a way of being able to say, yes, this 00:21:20.590 --> 00:21:21.790 definitively came from the source. 00:21:21.970 --> 00:21:24.730 And some of the providers actually support multiple ones. 00:21:24.730 --> 00:21:27.910 I think SendGrid supports two or three different approaches, so you 00:21:27.910 --> 00:21:31.589 can kinda gauge your verification method to, according to the 00:21:31.594 --> 00:21:32.729 skills and the abilities that you. 00:21:34.084 --> 00:21:34.874 CJ: That's cool. 00:21:34.943 --> 00:21:39.482 one thing too that has been interesting as we're like reviewing Stripes web hook 00:21:39.482 --> 00:21:43.653 situation is if you're building a web hook provider that's sending these web 00:21:43.653 --> 00:21:48.093 hook notifications, one of the challenges is versioning your event payloads. 00:21:48.273 --> 00:21:52.873 So that if you have, you're adding a new property, but you don't wanna break or 00:21:52.878 --> 00:21:54.443 you're removing a property even worse. 00:21:54.513 --> 00:21:57.093 You don't wanna break any of those web hook consumers, and 00:21:57.093 --> 00:21:58.203 so you have to version it. 00:21:58.203 --> 00:22:02.373 So now like each web hook endpoint has a different version and the payloads 00:22:02.373 --> 00:22:03.603 have different versions and stuff. 00:22:03.963 --> 00:22:08.193 And so when looking@webhooks.fyi, under Web Hook security, if you look at this 00:22:08.198 --> 00:22:13.413 like data list notifications option, that is really attractive to me because like 00:22:13.443 --> 00:22:15.213 then you don't actually have to include. 00:22:15.913 --> 00:22:19.868 any like too much stuff that's gonna get versioned, right? 00:22:19.868 --> 00:22:23.408 Like you can build a payload that will be very consistent across 00:22:23.408 --> 00:22:25.598 decades worth of versions, ideally. 00:22:25.928 --> 00:22:30.458 But then the consumer, when you receive the notification, depending on your S D K, 00:22:30.548 --> 00:22:36.338 that is then pinned to some specific A p I version can fetch the latest copy of that 00:22:36.338 --> 00:22:38.078 object that you're being notified about. 00:22:38.258 --> 00:22:41.168 You get the latest state, but you don't actually necessarily have to get 00:22:41.168 --> 00:22:42.878 that in the payload of the web hook. 00:22:43.418 --> 00:22:45.888 Keith: Yeah, so a little bit of background. 00:22:45.918 --> 00:22:50.408 a dataless notification, we said earlier, like the message passing of saying, here, 00:22:50.408 --> 00:22:52.058 the state of this thing has changed. 00:22:52.058 --> 00:22:53.198 Here's all the information about it. 00:22:53.378 --> 00:22:57.188 In a dataless one, instead of having all that information, all it has is a 00:22:57.188 --> 00:23:00.698 reference to the object that changed and the fact that it did change. 00:23:00.998 --> 00:23:04.058 And then you go back and you use that your eye to then pull back and 00:23:04.063 --> 00:23:05.978 say, okay, the thing has changed. 00:23:05.978 --> 00:23:07.928 This shopping cart status has changed. 00:23:08.408 --> 00:23:10.967 Tell me, that's actually what I recommend, not just for versioning, 00:23:10.996 --> 00:23:14.176 it mitigates some of that, but also if you have really sensitive information. 00:23:14.476 --> 00:23:18.856 So think of a healthcare use case where you don't necessarily wanna broadcast 00:23:18.856 --> 00:23:20.186 that information over the wire. 00:23:20.256 --> 00:23:24.508 CJ: It's also if I think about it a little bit, it's also, really great if you have, 00:23:24.557 --> 00:23:26.267 like a globally distributed network. 00:23:27.527 --> 00:23:31.586 Of like sharded databases where like some of your customers are in, the 00:23:31.586 --> 00:23:33.296 US and some are in the Australia. 00:23:33.476 --> 00:23:37.046 If you're just sending this like super lightweight dataless payload that 00:23:37.046 --> 00:23:42.806 says, here's the object ID that was updated, then like the API request 00:23:42.896 --> 00:23:47.336 from Australia will be routed to some AWS data center in Australia to 00:23:47.336 --> 00:23:50.666 fetch the object faster than, yeah. 00:23:50.666 --> 00:23:51.815 If it's located somewhere else. 00:23:51.845 --> 00:23:52.865 I don't know, feel like there's. 00:23:54.260 --> 00:23:54.650 Some, 00:23:54.830 --> 00:23:55.520 Keith: a really good approach. 00:23:55.520 --> 00:23:56.610 I hadn't thought about that. 00:23:56.680 --> 00:23:58.190 I need to add that to the site. 00:23:58.259 --> 00:24:01.740 CJ: it's, the, yeah, I think, yeah, if you're looking at those web hook 00:24:01.740 --> 00:24:06.751 security options, I think dataless is, pretty attractive, like going forward. 00:24:06.782 --> 00:24:10.052 Keith: we also have a section on there for like operational experience because 00:24:10.052 --> 00:24:13.382 while we started with a security mindset, we said, okay, as people are 00:24:13.382 --> 00:24:17.132 building and designing and working with WebBook, how do they operationalize 'em? 00:24:17.201 --> 00:24:20.051 you had mentioned like versioning of the payloads and things. 00:24:20.231 --> 00:24:23.231 There's also the, some capabilities around forward compatibility 00:24:23.561 --> 00:24:25.420 of when a web hook comes in. 00:24:25.420 --> 00:24:27.040 How do you support multiple keys? 00:24:27.160 --> 00:24:28.870 Because there's always that moment of like with a shared 00:24:28.870 --> 00:24:30.910 secret of my secret has been. 00:24:31.830 --> 00:24:34.590 I need to revoke the old one and generate a new one. 00:24:35.700 --> 00:24:39.120 Depending on the traffic and your web hook patterns and everything, you could 00:24:39.470 --> 00:24:43.920 actually miss requests, so the ability to revoke the old key and generate a new one. 00:24:44.040 --> 00:24:47.070 If you can have both of them running simultaneously, you don't 00:24:47.070 --> 00:24:48.690 necessarily miss any requests. 00:24:48.847 --> 00:24:49.087 CJ: Yeah. 00:24:49.087 --> 00:24:53.947 And I've seen sometimes like where each end point that you create in the third 00:24:53.947 --> 00:24:57.567 party, so. If you imagine the way that this usually works is you log into the 00:24:57.567 --> 00:25:02.037 third party, whether that's Slack or Zoom or Box or whatever, and there's some 00:25:02.037 --> 00:25:06.777 input box in your developer application settings where you're gonna enter a url. 00:25:07.407 --> 00:25:11.268 In many of these, the ones that will give you like a signing secret will 00:25:11.273 --> 00:25:15.553 generally give you a different well, Might give you a different signing secret 00:25:15.553 --> 00:25:17.113 per web hook endpoint that you put in. 00:25:17.533 --> 00:25:21.223 So sometimes if people wanna roll the key, they'll just put the same u URL 00:25:21.223 --> 00:25:25.194 twice , and then they'll get back like different keys and then like they'll 00:25:25.194 --> 00:25:27.994 have two running for a little while and then you can delete the old one. 00:25:28.043 --> 00:25:32.712 but yeah, I think it's, operationally it sounds like a bit of a nightmare, cuz you 00:25:32.712 --> 00:25:36.864 have to oh, let me run through the entire process of checking and verifying the. 00:25:37.964 --> 00:25:42.304 and then let me like catch an exception and do the same exact thing again 00:25:42.304 --> 00:25:46.373 to re-verify with like potentially, N Keys that you're handling. 00:25:46.913 --> 00:25:47.313 So 00:25:47.339 --> 00:25:50.884 Keith: and we all know that complicated processes scale really well, right? 00:25:51.276 --> 00:25:54.936 CJ: Yeah, it is just like any, anything that's complicated is going to break. 00:25:54.966 --> 00:25:59.174 And I see that PagerDuty is one of your web hook providers and so that's 00:25:59.174 --> 00:26:02.144 something you're gonna need when you build one of these complicated processes 00:26:02.144 --> 00:26:03.594 and someone tries to roll the key. 00:26:03.644 --> 00:26:05.594 . Keith: Yeah, PagerDuty is actually doing a number of things. 00:26:05.625 --> 00:26:08.865 they've got, like the zero downtime rotation is what we call that one, 00:26:09.195 --> 00:26:12.465 so that you're not going to miss webhooks in between and you're not 00:26:12.470 --> 00:26:13.845 gonna break downstream systems. 00:26:13.850 --> 00:26:14.575 But, I'm trying to think. 00:26:14.575 --> 00:26:17.755 I think HubSpot also implements some stuff around forward compatibility. 00:26:17.760 --> 00:26:21.235 So not just changing the key, but changing the signature method. 00:26:22.395 --> 00:26:24.940 because frankly we know that at some point we're gonna have 00:26:24.940 --> 00:26:26.140 to change our signing methods. 00:26:26.169 --> 00:26:29.079 I will also say there's, I think at least one or two companies 00:26:29.084 --> 00:26:30.919 that use MD5 for signatures. 00:26:30.989 --> 00:26:31.539 Don't, 00:26:31.609 --> 00:26:32.099 CJ: Yeah. 00:26:32.574 --> 00:26:33.943 Keith: don't we do name them on the site. 00:26:33.943 --> 00:26:37.774 I'm not gonna name them here cuz that's impolite, but at some point we're gonna 00:26:37.774 --> 00:26:39.394 have to change our signature methods. 00:26:39.694 --> 00:26:43.564 So having that forward compatibility, that multiple URL pattern, like having 00:26:43.564 --> 00:26:45.304 those things ends up being super powerful. 00:26:46.214 --> 00:26:46.339 Colin: Yeah. 00:26:46.549 --> 00:26:50.019 If you think that might be you can go to webhooks.fyi to verify. 00:26:50.048 --> 00:26:51.728 but you can also submit your company. 00:26:51.733 --> 00:26:55.808 So if you do follow these, there's a way to submit and contribute, 00:26:55.808 --> 00:26:57.488 like to add to that list, right? 00:26:58.448 --> 00:26:58.806 Keith: Oh, yeah. 00:26:58.806 --> 00:27:01.716 I should say we set this up entirely as a community site. 00:27:01.765 --> 00:27:05.406 so there's very light, any inro marketing on it, I think it says in the header 00:27:05.411 --> 00:27:06.586 and the footer, and that's about it. 00:27:06.615 --> 00:27:08.755 but this is all a public GitHub repo. 00:27:08.805 --> 00:27:12.846 go to, github.com/ngrok, webhooks.fyi. 00:27:13.056 --> 00:27:15.436 See where we're really tricky with the naming there. 00:27:15.504 --> 00:27:18.024 but we accept poll requests from every anyone. 00:27:18.029 --> 00:27:19.603 So we have, there's a web hook company. 00:27:19.603 --> 00:27:20.523 I think it's sw. 00:27:20.908 --> 00:27:24.968 That submitted, themselves and a bunch of their customers, we want to make 00:27:24.968 --> 00:27:28.398 this the definitive place that people can come to learn about webhooks 00:27:28.478 --> 00:27:30.518 and still have it totally neutral. 00:27:30.638 --> 00:27:32.328 So we don't sell webhooks. 00:27:32.348 --> 00:27:33.428 We're not interested in that. 00:27:33.608 --> 00:27:36.818 We just want the internet to be a little more secure, and we think 00:27:36.818 --> 00:27:37.928 this is one of the ways to do it. 00:27:39.233 --> 00:27:42.684 Colin: I think it's a great tool for if you're doing your first, you 00:27:42.684 --> 00:27:46.284 have a guide for web hook consumers as well as web hook providers. 00:27:46.584 --> 00:27:49.854 A lot of these are on the provider side, the security, things like that. 00:27:49.854 --> 00:27:53.364 But then on the consumer side, there's a whole bunch of kind of 00:27:53.364 --> 00:27:55.084 conventions that you have to learn. 00:27:55.153 --> 00:27:57.801 a lot of times, let's just say you're, you don't have your 00:27:57.806 --> 00:27:59.301 end groc tunnel on right now. 00:27:59.661 --> 00:28:03.491 If you have that turned off and Stripe tries to send a message to 00:28:03.491 --> 00:28:07.841 you, they're gonna do things like retrying until there's a certain 00:28:07.846 --> 00:28:10.551 point when they just say, I'm gonna give up and not keep sending it. 00:28:10.582 --> 00:28:11.992 what does that look like on your end? 00:28:11.992 --> 00:28:14.782 How do you verify as a consumer that you're not playing the 00:28:14.782 --> 00:28:16.502 same event more than once? 00:28:16.551 --> 00:28:19.521 there's some reasons why you would wanna replay a same event more than 00:28:19.521 --> 00:28:23.641 once, but, even that, that idea of dataless notifications becomes pretty 00:28:23.641 --> 00:28:27.460 interesting in that instance where it's have we seen this event before? 00:28:27.490 --> 00:28:29.500 Okay, if we have, we're not gonna do anything with it. 00:28:29.560 --> 00:28:33.950 Or let's go check and see what's changed each time versus some people I 00:28:33.950 --> 00:28:38.750 do know try to use webhooks as a pure integration framework, and there's some 00:28:38.750 --> 00:28:40.430 challenges there if you miss events. 00:28:40.990 --> 00:28:41.170 , right? 00:28:41.170 --> 00:28:42.860 Because it's not polling, you're not. 00:28:42.890 --> 00:28:47.000 but being able to go reach into the system with your API key to go get 00:28:47.000 --> 00:28:49.250 that latest data can help with that. 00:28:49.250 --> 00:28:53.479 I think for us, we do use a lot of webhooks to tell us something 00:28:53.509 --> 00:28:58.379 changed, but we usually use that to go pull the service to see. 00:28:59.179 --> 00:29:02.549 All the changes and maybe all the ones that we don't know about. 00:29:02.580 --> 00:29:05.919 so it's more of, instead of polling every hour or every day, we'll pull when we 00:29:05.924 --> 00:29:10.069 get a message from the system, which is also a good way of thinking about that. 00:29:11.274 --> 00:29:12.284 Keith: Yeah, absolutely. 00:29:12.384 --> 00:29:14.584 And There, there's the, provider section. 00:29:14.584 --> 00:29:17.044 There's a consumer section, best practices for both. 00:29:17.614 --> 00:29:19.384 Even the people that mostly consume. 00:29:19.384 --> 00:29:22.054 We found that internally, they're still building systems 00:29:22.054 --> 00:29:23.394 that are generating webhooks. 00:29:23.704 --> 00:29:26.254 Even if they don't go outside your firewall, outside your 00:29:26.254 --> 00:29:27.724 infrastructure, that's fine. 00:29:27.724 --> 00:29:30.954 Remember, originally, we start talking about the value of webhooks 00:29:30.954 --> 00:29:34.054 is the fact that we all know HT d p and we all know J S O N. 00:29:34.124 --> 00:29:36.824 Don't generate your own custom protocol for these things. 00:29:36.854 --> 00:29:41.724 Even if your only consumers are inside your company, still follow best practices 00:29:41.729 --> 00:29:46.364 because all it takes from, for that web hook to then be shared publicly is some 00:29:46.364 --> 00:29:50.414 senior exec at your company going, wow, we have partners, we have customers 00:29:50.414 --> 00:29:51.824 who would love that information too. 00:29:52.244 --> 00:29:56.634 And now suddenly you're entirely internal tool set just got published to the world. 00:29:56.704 --> 00:29:56.914 CJ: Yeah. 00:29:56.942 --> 00:29:57.962 I had a couple of questions. 00:29:57.962 --> 00:30:01.512 If we could circle back to the, like the building and 00:30:01.512 --> 00:30:02.892 hosting of the site on GitHub. 00:30:02.962 --> 00:30:06.440 it, I really like this approach in building and public Also, I noticed that 00:30:06.470 --> 00:30:08.330 it's using Mark Doc, which is pretty cool. 00:30:08.330 --> 00:30:09.849 That's fun to see in the wild. 00:30:10.929 --> 00:30:13.937 , but also, yeah, have you found this to be like a pretty successful 00:30:13.937 --> 00:30:16.127 way to engage in open source? 00:30:16.127 --> 00:30:19.547 I, it's also seems like a great lead gen for ngrok and 00:30:19.967 --> 00:30:21.227 just generally how's it going? 00:30:21.227 --> 00:30:23.507 Would you recommend this to other companies that are trying 00:30:23.507 --> 00:30:24.857 to participate in open source 00:30:24.907 --> 00:30:28.507 Keith: we decided to, to launch it on GitHub because it was quick. 00:30:28.507 --> 00:30:29.387 It was easy. 00:30:29.438 --> 00:30:31.728 we, had already collected all the information behind it. 00:30:31.728 --> 00:30:35.028 So really the marginal effort was getting a reasonable design in front of 00:30:35.028 --> 00:30:39.158 it and then generating some, Graphics to show like what the different web 00:30:39.158 --> 00:30:40.598 hook flows were and things like that. 00:30:40.598 --> 00:30:44.228 So I think it's, I've been very happy with the results so far. 00:30:44.408 --> 00:30:48.038 Yeah, we have Google Analytics on it, but we don't have a ton of like marketing 00:30:48.038 --> 00:30:49.878 analysis tools or anything like that. 00:30:49.949 --> 00:30:55.609 but realistically, like seeing people use this, hearing how people Been informed 00:30:55.609 --> 00:30:57.289 by this process, I think is great. 00:30:57.529 --> 00:31:02.389 We had, I think two, maybe three weeks ago, zoom announced that they're doing 00:31:02.389 --> 00:31:05.749 a major update to their webhooks and they announced the platform, they 00:31:05.749 --> 00:31:09.799 announced all the changes, and in their documentation itself it said, we use 00:31:09.799 --> 00:31:12.469 webhooks.fyi to make these decisions. 00:31:13.164 --> 00:31:14.814 CJ: Whoa, that, 00:31:14.839 --> 00:31:15.619 Keith: Yeah. 00:31:16.219 --> 00:31:18.409 That was so cool. 00:31:18.829 --> 00:31:23.188 Like our initial goal with Web outside FOI was to take the information we had and 00:31:23.188 --> 00:31:24.433 organize and make it available to others. 00:31:25.318 --> 00:31:29.998 The aspirational goal was that we start nudging the industry towards better 00:31:30.003 --> 00:31:34.454 practices, was amazing to have somebody like Zoom come forward and say, your 00:31:34.454 --> 00:31:36.294 work had inspired us to do this better. 00:31:36.364 --> 00:31:37.594 it was a mic drop kind of moment. 00:31:38.149 --> 00:31:40.688 Colin: Yeah, there've been these webhook communities for a while. 00:31:40.688 --> 00:31:44.388 Like I've been in the webhooks Google group for a long time, but like people who 00:31:44.528 --> 00:31:47.858 are gonna go consume or create their own web hook system, I don't know that they're 00:31:47.858 --> 00:31:50.378 going to join a Google group or go. 00:31:50.468 --> 00:31:53.628 I think like webhooks.com used to be a directory, but like 00:31:53.628 --> 00:31:55.278 that site doesn't exist anymore. 00:31:55.348 --> 00:31:56.628 There's a. 00:31:57.578 --> 00:31:59.378 Webhooks, r slash webhooks. 00:31:59.498 --> 00:32:01.188 Not a very lively place. 00:32:01.238 --> 00:32:02.438 not really where people are going. 00:32:02.438 --> 00:32:06.077 I think, having the powered by ngrok and just like being a little bit of 00:32:06.082 --> 00:32:10.110 an organizer and giving, some very good opinions and also like making 00:32:10.110 --> 00:32:13.621 it open so that people can contest some of those, oh, you know, so. 00:32:13.691 --> 00:32:17.272 Something new has happened that we now believe should be, the new standard 00:32:17.272 --> 00:32:19.492 for security or a new option, right? 00:32:19.492 --> 00:32:21.822 People can do a poll request and contribute to it. 00:32:21.851 --> 00:32:25.481 it's very similar to like, whenever someone decides to go write their own 00:32:25.481 --> 00:32:29.660 authentication from scratch, you want as many eyeballs on that as possible. 00:32:29.660 --> 00:32:33.470 And that's why so many people use these open source authentication tools 00:32:33.950 --> 00:32:35.900 because so many people have seen them. 00:32:35.900 --> 00:32:38.170 And I think, you guys are giving some credibility. 00:32:38.715 --> 00:32:40.365 But then everyone's gonna benefit from it. 00:32:40.395 --> 00:32:41.895 Zoom's adding credibility to it. 00:32:42.345 --> 00:32:43.365 We're at orbit. 00:32:43.365 --> 00:32:45.675 We're gonna take a look at our webhooks and see how we 00:32:45.675 --> 00:32:47.205 stack up against these, right? 00:32:47.205 --> 00:32:50.755 And figure out like, what are we missing or what are we doing right? 00:32:50.786 --> 00:32:54.094 and it's a good way to just close any of those windows that might, we 00:32:54.094 --> 00:32:55.694 might have left open accidentally. 00:32:55.764 --> 00:32:58.955 Keith: Yeah, and frankly, Sometimes you don't know what questions to ask. 00:32:59.145 --> 00:33:01.725 Like when we first started digging into this, like I wasn't even 00:33:01.725 --> 00:33:05.115 thinking about forward compatibility of changing the hashing algorithm. 00:33:05.325 --> 00:33:07.995 I was thinking about changing keys cuz that's something we just 00:33:08.000 --> 00:33:09.375 have to do occasionally anyway. 00:33:09.375 --> 00:33:13.684 But changing the ha hashing algorithm, I said, oh yeah, Allen Shreve, our ceo. 00:33:13.689 --> 00:33:14.914 He's yeah, we need to think about this. 00:33:14.914 --> 00:33:15.694 And I was like, oh. 00:33:16.549 --> 00:33:18.019 Yeah, actually that makes a lot of sense. 00:33:18.019 --> 00:33:22.848 And despite being, in Web Oak for 10, 12 years at this point, it wasn't 00:33:22.848 --> 00:33:24.018 something I'd really thought of. 00:33:24.438 --> 00:33:28.068 And so we're trying to let the next people know, Hey, look, here 00:33:28.073 --> 00:33:29.208 are a consideration you have. 00:33:29.478 --> 00:33:34.158 Even if you don't choose to think about forward compatibility, that's fine, but 00:33:34.163 --> 00:33:37.368 at least you knew that it's something that you might want to consider. 00:33:38.133 --> 00:33:38.553 CJ: Totally. 00:33:39.003 --> 00:33:43.293 Another thing that comes to mind with for forward compatibility too, and like 00:33:43.293 --> 00:33:47.463 a lot of the comments that I'm making come back to adding stuff into SDKs. 00:33:47.823 --> 00:33:52.022 So like when we talk about Dataless or Yeah, it's, you're gonna lean heavily 00:33:52.022 --> 00:33:54.343 on the sdk, when looking at H Mac. 00:33:54.393 --> 00:33:56.283 verification, which is what we use at Stripe. 00:33:57.018 --> 00:34:02.417 There are helper methods in the Stripe SDKs in all of the official SDKs that will 00:34:02.417 --> 00:34:06.654 do all of the fancy, crypto creating the H Mac, you just have to give it, here's 00:34:06.659 --> 00:34:11.494 the signature and here was the request, and then let the SDK figure it out. 00:34:11.499 --> 00:34:15.366 And what's nice about that is that, again, you're, you can depend on 00:34:15.366 --> 00:34:17.466 the SDK for forward compatibility. 00:34:17.466 --> 00:34:21.665 So as maybe as the, as the payload is using different signing. 00:34:22.835 --> 00:34:26.585 Algorithms, you can upgrade those inside of the SDKs. 00:34:26.585 --> 00:34:29.574 And so then it's just a matter of oh, let me bump my SDK version and 00:34:29.574 --> 00:34:32.012 maybe put in a new key or drop the. 00:34:32.582 --> 00:34:36.759 The public key somewhere in order to handle the verification so that, like 00:34:36.909 --> 00:34:41.559 I also, I have implemented lots of web hook endpoints that use H Mac and 00:34:41.559 --> 00:34:43.239 they don't have helpers in the SDKs. 00:34:43.269 --> 00:34:45.659 And every single time it's ah, how does this work again? 00:34:45.659 --> 00:34:49.829 And like it's so finicky cuz you have to get it perfect or it won't work at all. 00:34:49.829 --> 00:34:52.908 And so it's great that you have the code on, WebBook FYI, 00:34:53.363 --> 00:34:55.668 Keith: that's one of the kind of horrifying things we found. 00:34:55.673 --> 00:34:58.248 Like that moment of, how do I do this again? 00:34:58.428 --> 00:35:01.648 We found, I don't know, 10, 15% of the docs didn't actually 00:35:01.653 --> 00:35:03.508 have SDKs or code samples. 00:35:03.579 --> 00:35:06.859 It was like a bulleted list of get this field, then do this, 00:35:07.069 --> 00:35:08.059 and I'm like, wait a minute. 00:35:08.539 --> 00:35:11.239 You are trying to appeal to developers in general. 00:35:11.239 --> 00:35:13.519 You don't know their skill level, you don't know they're 00:35:13.524 --> 00:35:14.959 understanding these topics. 00:35:15.199 --> 00:35:17.299 You're expecting them to do it right the first time. 00:35:18.559 --> 00:35:21.879 I'm like, come on, this is, you're making life miserable for them. 00:35:22.309 --> 00:35:25.159 And I always defer to use the SDK if it's available. 00:35:25.229 --> 00:35:29.324 but every company has to prioritize and they're going to not be able to tackle 00:35:29.354 --> 00:35:31.124 every language, every framework out there. 00:35:31.124 --> 00:35:34.784 And I, I don't criticize anyone for that, but there's gonna be times where 00:35:34.789 --> 00:35:38.354 you are working in an environment that they do not have the tooling for. 00:35:38.984 --> 00:35:41.834 So you have to figure out, okay, can I do this myself? 00:35:42.314 --> 00:35:42.704 CJ: right? 00:35:43.184 --> 00:35:48.014 Is that, so it sounds like inside of Enro now you can use it in production 00:35:48.014 --> 00:35:49.814 to handle message verification. 00:35:50.504 --> 00:35:50.994 Is that. 00:35:51.018 --> 00:35:55.183 is exposing SDKs from the ngrok side that handle that? 00:35:55.183 --> 00:35:57.293 Is that something that y'all have thought about at all? 00:35:57.364 --> 00:36:00.354 providing those open source as oh, hey, this is just like 00:36:00.359 --> 00:36:01.704 the standard H Mac thing. 00:36:01.704 --> 00:36:03.654 You pass in Slack or whatever. 00:36:03.654 --> 00:36:04.074 I don't know. 00:36:04.224 --> 00:36:06.094 And then it just will verify things for you. 00:36:06.634 --> 00:36:06.994 Keith: Yeah. 00:36:07.025 --> 00:36:09.864 the way it works on our side is that you choose your web hook provider. 00:36:09.864 --> 00:36:12.805 So if you're on the dashboard, you choose Slack and you put in, I think 00:36:12.805 --> 00:36:16.165 it's the shared secret for Slack, and then we handle it in the cloud. 00:36:17.605 --> 00:36:21.025 We've considered, how do we provide general tooling for that? 00:36:21.025 --> 00:36:22.105 That's really hard. 00:36:22.495 --> 00:36:26.734 We've tried to say, can we do a inject your own logic, like a Lambda style 00:36:26.739 --> 00:36:31.414 kind of thing for web book verification that scares the crap outta me executing 00:36:31.414 --> 00:36:35.773 other people's code in our environment as eh, Yeah, those are some interesting 00:36:35.778 --> 00:36:39.034 questions that I'm not sure we're willing or ready to answer at this 00:36:39.034 --> 00:36:42.784 point, but as long as you're in the flow, you can do a lot of things. 00:36:43.234 --> 00:36:43.519 CJ: totally. 00:36:44.059 --> 00:36:48.109 The fact that there were 49 different implementations across 50 providers 00:36:48.229 --> 00:36:52.558 also, is so frustrating because the way that I like to implement a web 00:36:52.558 --> 00:36:57.088 hook endpoint is just, I want like slash webhooks and I want every third 00:36:57.088 --> 00:37:00.518 party that I integrate with for that application to all go to slash webhooks. 00:37:00.988 --> 00:37:04.678 And now you have to like fork on the source, like where did this come from? 00:37:04.678 --> 00:37:05.277 And now you 00:37:05.287 --> 00:37:06.247 Colin: big case statement, 00:37:06.357 --> 00:37:07.857 CJ: Exactly big case statement. 00:37:07.857 --> 00:37:10.319 And some people think that, synchronous webhooks are cool and 00:37:10.319 --> 00:37:11.739 asynchronous webhooks are cool. 00:37:11.829 --> 00:37:12.489 Like all this stuff. 00:37:12.489 --> 00:37:16.948 I'm like, Hey, that is another huge, I think selling point of letting N Groc just 00:37:16.948 --> 00:37:21.718 do it for you is that, hey, if you figure out all of the verification piece and I 00:37:21.723 --> 00:37:24.909 don't have to worry about that, then my web hook endpoint is literally just, take 00:37:24.909 --> 00:37:28.698 the payload, stick it in the database, and then kick off a background job to process 00:37:28.698 --> 00:37:30.738 this later and then respond with 200. 00:37:30.738 --> 00:37:32.099 And I'm like gonna walk away. 00:37:32.168 --> 00:37:33.008 and yeah. 00:37:33.668 --> 00:37:35.688 Keith: there was a great article going around recently called, 00:37:35.719 --> 00:37:37.429 the Self-Provisioning Runtime. 00:37:38.029 --> 00:37:41.928 And it was the whole mindset of that is as you're building these stacks and these 00:37:41.928 --> 00:37:47.568 operating environments, if we can build tooling and support infrastructure so 00:37:47.573 --> 00:37:51.708 that the developer building their app only has to worry about their business logic. 00:37:53.313 --> 00:37:57.213 they get more efficient, they get more effective, and they can scale. 00:37:57.213 --> 00:37:59.463 They can operationalize things that much easier. 00:37:59.463 --> 00:38:03.213 It's really the, that's the mindset behind most of the DevOps philosophy 00:38:03.633 --> 00:38:07.803 is how do we make sure that developers stay focused on building business logic? 00:38:08.013 --> 00:38:11.043 And so we actually had the same concept on the ngrok side of things. 00:38:11.043 --> 00:38:13.783 So how do we just take the security stuff off? 00:38:13.817 --> 00:38:16.007 just make it so that it works by default? 00:38:16.427 --> 00:38:19.787 And you don't have to do this because implementing OAuth, implementing 00:38:19.787 --> 00:38:21.387 webhooks, like all these things suck, 00:38:21.457 --> 00:38:21.857 . CJ: Yep. 00:38:21.885 --> 00:38:24.165 Keith: it's the exact same patterns over and over again, but it's 00:38:24.165 --> 00:38:26.205 not entirely the same pattern. 00:38:26.205 --> 00:38:28.125 It's really close to the same pattern. 00:38:28.425 --> 00:38:30.225 It's 49 out of 50 times. 00:38:30.225 --> 00:38:33.705 It's different, but it's just different in little ways, and it's irritating. 00:38:33.874 --> 00:38:34.384 Colin: Absolutely. 00:38:34.389 --> 00:38:35.284 We found that link. 00:38:35.284 --> 00:38:38.484 We'll put it in the show notes cuz I think, that idea is I 00:38:38.484 --> 00:38:39.884 think with the stripe, listen. 00:38:39.935 --> 00:38:42.484 framework too, like being able to listen to those webhooks. 00:38:42.784 --> 00:38:46.414 I see this, we'll probably talk to Alan about this when we have him on 00:38:46.414 --> 00:38:49.844 the show, but ngrok go looks really exciting too, just being able to 00:38:49.849 --> 00:38:52.554 like, have your app start listening. 00:38:52.625 --> 00:38:56.465 For you rather than have like I, I like running ngrok locally and 00:38:56.465 --> 00:38:57.766 just like seeing, those things. 00:38:57.766 --> 00:39:01.036 But as a developer or even as someone who's focusing on developer experience, 00:39:01.036 --> 00:39:06.256 like that time to first hello world or time to that first light bulb going 00:39:06.256 --> 00:39:10.277 off and it's all these steps that we have to do to be secure are only 00:39:10.277 --> 00:39:14.018 gonna slow that down if you don't provide ways of, Self provisioning, 00:39:14.018 --> 00:39:16.588 runtime or helpers in your SDKs. 00:39:16.638 --> 00:39:19.698 and so it's a good thing to think of if you're developing developer tools 00:39:19.698 --> 00:39:23.808 or if you're in developer marketing or developer advocacy and you're trying 00:39:23.808 --> 00:39:26.578 to figure out, yeah, everyone seems to fall off at this point where we ask 00:39:26.583 --> 00:39:29.078 them to go do a ed list of 10 things. 00:39:29.108 --> 00:39:30.608 what can we take off their plate? 00:39:30.968 --> 00:39:32.738 What can we push to the edge there? 00:39:32.738 --> 00:39:36.527 And yeah, it's, I think the thing that I'm most mind blown why 00:39:36.527 --> 00:39:37.727 right now is just how many things. 00:39:39.097 --> 00:39:40.482 I'll go back to Twilio right now. 00:39:41.952 --> 00:39:44.872 and, between Jeff and Alan and yourself. 00:39:44.941 --> 00:39:49.001 yeah, it was a, around that time was a, was what a time to be on 00:39:49.001 --> 00:39:51.861 the internet and all the things that we get to benefit from today. 00:39:52.681 --> 00:39:57.546 Keith: I, I think say 2009 through 2012, there was a lot of foundation laid 00:39:57.906 --> 00:40:00.826 for kind of an internet renaissance. 00:40:00.856 --> 00:40:04.947 and some of that has led to all the, these API companies, a lot of it's led 00:40:04.952 --> 00:40:06.357 to some of this machine learning stuff. 00:40:06.777 --> 00:40:11.367 Machine learning like ChatGPT would be a lot harder to use and implement right now 00:40:11.517 --> 00:40:13.227 if we didn't have the APIs behind the. 00:40:14.187 --> 00:40:18.417 And the APIs rewind 12 years ago and people were just getting their hands 00:40:18.417 --> 00:40:19.887 and their heads around these things. 00:40:20.217 --> 00:40:23.968 So I think, yeah, it was a cool time to get started in the space 00:40:24.238 --> 00:40:27.009 and I look forward to what's the cool thing to get started with now? 00:40:27.257 --> 00:40:30.767 CJ: I was just checking to see if OpenAI had webhooks, but I'm like, 00:40:30.827 --> 00:40:32.517 what would that use case even be? 00:40:32.586 --> 00:40:35.596 instead of webhooks, they just have like really long requests. 00:40:35.624 --> 00:40:39.463 you make an API call and it takes, I'm not bagging on it, but yeah, 00:40:39.463 --> 00:40:42.203 like two seconds later you'll get back your check completion. 00:40:42.274 --> 00:40:42.694 but. 00:40:43.297 --> 00:40:45.457 earlier we talked about the Stripe listen command. 00:40:45.457 --> 00:40:51.127 So at Stripe we built a custom CLI for integrating against Stripe, and 00:40:51.127 --> 00:40:52.297 it has a bunch of different features. 00:40:52.297 --> 00:40:57.137 One of them happens to be Stripe, listen, which is a tunneling, a tunneling. 00:40:57.557 --> 00:41:00.147 Mechanism so you can receive your stripe webhooks without 00:41:00.167 --> 00:41:01.037 having to set anything up. 00:41:01.037 --> 00:41:03.398 So it will set up the WebBook endpoint and also deliver it. 00:41:03.469 --> 00:41:06.949 and as part of that we have a VS code extension. 00:41:06.949 --> 00:41:09.709 So like from inside of VS code you can start the listener. 00:41:09.889 --> 00:41:13.429 And I found that there's also a ngrok for VS code extension. 00:41:13.429 --> 00:41:16.219 And I assume this works very similar, where you can just like fire up 00:41:17.569 --> 00:41:18.659 ngrok directly inside of your editor. 00:41:18.728 --> 00:41:22.208 Keith: Yeah, just like that early thing of a wanting to set his phone 00:41:22.208 --> 00:41:23.648 down, keep his hands on keyboard. 00:41:23.888 --> 00:41:25.538 We have that exact same mindset for this. 00:41:25.587 --> 00:41:29.126 Phil Nash, another Twilio alum, built that vs. 00:41:29.131 --> 00:41:31.176 Code extension years ago at this point. 00:41:31.206 --> 00:41:35.076 but it's all about how do we keep you in the environment that you're working in? 00:41:35.316 --> 00:41:37.156 How do we not interrupt your flow? 00:41:37.206 --> 00:41:38.586 you wanna be effective? 00:41:38.646 --> 00:41:41.316 Let's make it so that you are and just get outta your. 00:41:41.758 --> 00:41:42.868 CJ: totally love it. 00:41:43.203 --> 00:41:43.573 Colin: Awesome. 00:41:43.603 --> 00:41:46.273 I think that's a great place to leave people wanting more. 00:41:46.273 --> 00:41:47.743 They we're gonna put a bunch of links. 00:41:47.743 --> 00:41:51.793 I found a really good article from 2007 from Jeff Lindsay 00:41:51.793 --> 00:41:54.793 talking about how webhooks are going to revolutionize the web. 00:41:55.183 --> 00:41:56.213 It's a good read. 00:41:56.242 --> 00:41:58.822 gets into a little bit of the message handling and the small 00:41:58.822 --> 00:42:02.701 talk type message passing that, that we talked about here today. 00:42:02.750 --> 00:42:06.640 but where can people find more about you and all of your work on the internet? 00:42:06.640 --> 00:42:06.880 Keith? 00:42:07.505 --> 00:42:08.135 Keith: Yeah, absolutely. 00:42:08.206 --> 00:42:11.446 my day job is inro, so ngrok.com, that's the place for everything. 00:42:11.626 --> 00:42:15.396 If you need to reach me specifically, you can email me danger@ngrok.com. 00:42:15.446 --> 00:42:16.866 I respond to that pretty quickly. 00:42:16.897 --> 00:42:19.507 if you wanna find me online, everywhere else, I'm Casey Software. 00:42:19.507 --> 00:42:22.077 That's c a s e y software. 00:42:22.103 --> 00:42:24.138 and definitely check out webhooks.fyi. 00:42:24.138 --> 00:42:25.218 It is the source. 00:42:25.218 --> 00:42:28.056 We really wanna make it available to everyone and, inform the internet. 00:42:28.056 --> 00:42:28.626 Make it a little more. 00:42:29.213 --> 00:42:31.793 CJ: Thanks a ton for all your hard work on that resource. 00:42:31.798 --> 00:42:35.252 I think it's a wealth of knowledge and information and yeah, it's 00:42:35.252 --> 00:42:36.842 making the whole community better. 00:42:36.842 --> 00:42:38.202 So really appreciate that, Keith. 00:42:38.271 --> 00:42:41.631 yeah, so as always, you can head over to build and learn.dev to check out 00:42:41.631 --> 00:42:45.801 the links to the resources that we've just mentioned and the show notes. 00:42:46.071 --> 00:42:47.421 That is all for this. 00:42:48.291 --> 00:42:48.891 Thanks folks. 00:42:48.891 --> 00:42:49.591 We'll see you next time.