One day, one day, open wide death and get ready to stuff your face with Joffah for CSM Joe Biden to work for a careful weekend. It's off to the 11th of the HCS, the craziest, the tastiest web development treats coming in hot here is West Sarah Kuda, boss and Scott L. Taro and L. Go to Litzky.
Whoa. Welcome to syntax and this Monday's featuring, we're gonna be talking to all about web hooks. My name is Scott Taro and I'm a developer, Denver Colorado and with me, as always, is my man, the man with the boss. How's it going, my guy?
It is a lovely Monday morning. We are just hanging out here in the Def Shack, whatever you got the whole deck and we're just cruising in. How you doing? We're almost at 400 episodes and we've never done a webhooks, we talked about them, but we've never done a whole show on what web hooks are.
So, we've already said the word web hooks and we also like many other things in development and we're in those concepts that's way scarier than it actually is. You're the word web hooks and you're like, oh man, this is like Spider-Man or something? No, it's not Spider-Man. It's like, it's like, it's really friendly.
It's Spider-Man, but it's pretty cool. So, before we get into that, let's talk about some of our sponsors, they wish our linode and log, right? What's my take, linode and all the log, right? Yeah, linode is a cloud computing that developers trust.
So, if you need any sort of cloud computing, most likely you need some hosting for your application, you listen to this podcast and maybe you're a node developer, you want to put your node application up on a server somewhere. Linode offers that and they have a pretty wicked $100 worth of free credit as part of this ad read. In addition to Linux hosting, you can run your node or Ruby or PHP apps on, they also have a dedicated CPU, they have high memory, they've got GPU, Kubernetes, block storage, they have AWS compatible storage, which means that if you're using AWS packages and any of your stuff, you can just hook up linode with it and it would just work just pretty sweet. So, if you want to host your website or your application or your images anywhere, so check out linode.com4s.entax.create a free account.
It's going to give you a $100 in free credit and they also have 24.7, 365 human support. No tiers or handoff or guard, those are your plans. That's just pretty cool. Thank you.
No, first one. Six, this is also sponsored by LogRacket, which is the perfect place to see all of your errors and exceptions happen. Do your user so that you can see them as if you were your user. You're talking about the give you a scrubble video replay with the network logs and console logs and error handling.
So, you can possibly need it to do both this thing. It's all here in more. In addition to having that scrubble video replay, it's like imagine trying to solve a crime, while having a video paper of the crime being committed along with all the information about everything that was involved in the crime. Yeah, that's my code.
The crimes were committed. Yes, and LogRacket will help you solve those crimes. They are a graphic crime dog here. So logracket.com forward slash syntax and you'll get 14 days for you.
This is one of those tools that makes solving bugs so much faster. It's grab yourself onto a rocket and blast off and you will be solving bugs in time with the log. Okay, we have the hooks and I'm not talking about Spiderman hooks. They're already there by the matter.
I think so. So, what are Webhooks? Yeah, so Webhooks are pretty common in applications where you have a server or a service and it needs to ping or send some data to another service when something happens. So, I like to think of them as callbacks for events that happen when something happens.
Ping this URL with the following data and let them know that this happens. So, the best way to understand what that is is still looking at some examples. So, when someone bought a shirt from my JavaScript shirt store, it would send a webhook off to my server and say this person bought a shirt and it would give us a huge payload of data and I would say, okay, well, I now need to go ahead and do a few things. And one of them is I need to save them to the database.
I need to create a shipping label. I need to change their status from pending to save a couple things I need to happen there. Another example is you want to trigger a build of a website. So, one of our other sponsors, Prismic, is this actually Webhook the Webhook.
It's not even code that I wrote. Is that a Vercel has the ability to rebuild itself based on a URL that can get pinged. And Prismic has the ability to send a Webhook when some data changes. So, you can take the Webhook from Vercel, put it into Prismic and whenever any of the data in Prismic is updated, it things Vercel, Vercel rebuilds the website into play it too.
Another one I use is Stripe or PayPal. If somebody uses a stolen credit card to buy a course and that is Chargeback happens, Stripe will send me a Webhook and say this is a URL on my website. So, somewhere in the URLs of my website that sells courses will have a URL that you hit that says Webhook or Chargeback and it will say the person with the following email address that did a Chargeback and then I can then look up the account that has that email address and lock it because more often than not someone stole a credit card and it uses my course. So, you can automatically just lock those and show them hey, sorry, something happened.
Please get in touch with us and we'll figure it out. Do you use any Webhooks in your course platform Scott? Yeah, and we mostly use them again like in our payment flow, especially for subscriptions. You know, a user subscription can be updated for several reasons what it would have passed to.
It's been charged again for the next month. It's been renewed. It's been a credit card and not data or something like that. And the processor will send the Webhook with all that information relevant information to our server and we know there are any of your information in every our Twitch.
But let's say you were past two, you didn't pay. We want to be able to make sure that we adjust our roles for your account accordingly so that you have access to what you're paying or not paying for. So, we get that information and then we get your downgrade to your upgrade to your whatever based on that Webhook. So, we're actually using for our video platform to whenever we upload something because we upload a file and then it needs to process.
We're a little bit on their end and then we'll get an message saying it's ready. So, we use Webhooks like that. You know, I like to think about them as being just like, you know, you have a user interacts with your site to write or anything. They're sending a post request to your server.
But this is sort of like a request that's going from server to server that's being initialized by a server now by a user, right? But there's not a whole ton of difference between a request being sent from a Webhook and request being sent from a user. It's just a robotic computer reader. Yeah, it's just a robotic computer user and they will often not be sent immediately.
They'll be sent when something happens, when a credit card is approved. That's another popular thing. Sometimes you can take credit card info, but the charges will go through the Amazon as this. The charges will actually go through for five minutes.
So, I'm assuming on their end, and somebody actually even sent me to eat this. Amazon has their own version of Webhooks. If both of the services are using AWS, you can use the Amazon specific version which is pretty nifty. But let's talk about the sending end and receiving end of Webhooks.
So, generally the way that as Webhooks is that you have a service, whether it's a CMS or a something like Stripe or PayPal or it's an online store. And that is a great way to hook different services together. So, when somebody saves a bunch of data, then you usually get an interface that you log into. You can say when this thing happens, then let me go ahead and you can select the method, post, put, patch, delete any of those HTTP methods.
And then you can also send it over. I actually had a call with one of our other sponsor's here today. They have this thing called rock, which is the ability to query anything from the data. And you can use the rock queries in your Webhooks.
So, you can say whenever a product that is more than $50 is updated, then ping the following URL and in that you can say what data it will get. And he had his anything along with him, but off in just a second. And then on the other end, it's generally you, the web developer, are writing some code. This is the sort of the receiving end.
You are writing an end point or a GraphQL function that will accept the incoming request. And then it's up to you to go ahead and send a successful send back. A lot of the good web services will email you if a Webhook sends like a 404 or 500 error back. And like I know specifically, I use Snipcart for selling my teachers.
And if one of the Webhooks failed, it would tell you what the request was, what the body of the request was. So you can see what data was being sent, what the response from the server was, which is really handy if you're trying to figure out what happened as well as the ability to try the Webhook again, which is super, super handy. Yeah, the best webhook interfaces for the ones that have like sent them, like a full history of that sense. This message at this time you click on it and you can see the full object of all the data that was like that to me is the gold standard for dealing with like knowing what's that.
But yeah, most of the time they do expect you to send some sort of specific response, like 200 response, and so on the receiving end, you have to think about these things. They were normal routes. These are just normal routes. The data's going to come in as normal requests.
So much of what I think I would want to get across in this episode is these Webhooks are nothing more than just requests. So if you have a server side route that's accepting this request, the normal request come in. It's just not being initiated from a user to save like I mentioned before. So on the receiving end, we set every request, we send that whatever we want to do.
And in the middle of between there, we do whatever we need to do with that data, whether it is a user records or by other things or other events that type of deal. Talk really quickly about payloads. Generally the body of the request will either be forming coded data or JSON encoded data. And you have to either parse that out or if you're using any sort of server side framework to often detect that and parse it out to an object for you.
It also tells you what is sent. And then more importantly, it will also come usually they will come with a bunch of headers that have tokens in them. And those tokens can be used to check if the request coming in was legitimate or not. Because you have these publicly available URLs on your server that anyone can hit.
And if somebody figures out what data to appropriately hit that Webhook with, then they could potentially be sending like, oh, well, send me t-shirts for free or something like that. So the way that you sort of authorize these things is that you can make sure that the like often like Striple says, these are our IP addresses. And any request that isn't coming from one of these IP addresses you can consider to be invalid. So you can just reject it or put that in a firewall rule if you're using a service that has a firewall.
But then also you can take those authorization tokens and you can go back to the service like a snip card or Striple say, hey, somebody just came over and said they want me to mail a Mathesia and they said 49873FR. It was at you and they'll be like, yeah, that was me. Definitely make sure that the request coming in are valued against the service that is supposed to be sending them. It is another back and forth, which can sometimes if a Webhook is waiting on your data to be sent back, that can add a little bit of overhead in terms of time for the data to come back.
But you kind of have to do that. So I think you can also do it without the request of the service because you will have a secret in your own service environmental variables and they will send you a token and using that token in your own secret. You can see if there is legit or not as well. Yeah, that leaves verify.
But you know, the information is correct. Yeah, that's no good. So like an end to next part is part of our Webhooks besides the fact of getting over the fact that you know, it's a dirty kind of thing, right? Is testing them because working locally you might be thinking, okay, you typically when you work with a Webhook somewhere like a Webhooks or a Webhooks, right?
They give you a place to have maybe like a URL you can paste in there and you can send test events. Usually there's a bunch of send to test events and strike, I remember that you can send like any of the events which is awesome, but in range rates just like send a check event just to send a check and that's all they do. But you're usually giving option to test these things and you as an owner might be saying, okay, let me just paste in the local host work 3000 here. Let me tell you that doesn't work because that's the local URL.
That's not to send anything to your computer to your local host work 3000. It just doesn't work. So there's a number of tools that people use for this type of deal. And what they basically do is they set up a public URL that redirects to essentially your IP in your port to send that message.
You might be more or while to give a little bit deeper of an explanation there if one needs to be. The main one of these tools I think that people use in most is ngrock and a g rok. It's not like local tunnel. That's one of them is local tunnel.
Yeah. I just looked on for a while and it was great, but there was a problem with local tunnel where basically the way that is you assign like west boss dot local tunnel.me And then that's your URL for your machine and it exposes whatever's running on 40,000 to the wider internet. And that's great if you want to be able to show somebody a website that's hosted on your computer, but they throw a little like, hey, this is not a real website often in front of it where you just press OK because I think local tunnels use a lot for people getting quick and easy domain names for standing people. So I was running into problem with that because the web hook would hit this intermediary page and not know what to do.
So I had to move over to end rock and rock doesn't let you have a consistent domain name for free. Yeah, free. You got to pay. So I had to pay for end rock, which is not at the end of the world.
It was worth my money in that case and rock was rock solid. And you want a consistent domain name for your computer because when you're setting up the URL every single time you restart your local tunnel or end rock. Which is a pain because it's one of the things you forget and you send the web. Yeah, I was a program and they're like, oh, wait, the URL changed by like one of these two these kind of generally here.
That is like an obvious. Yeah, definitely worth the money especially if it's something you're going to be working regularly or obviously you're working in a team at small cost for a company to pay for you. But end rock cool standard for me. It is one that I use as well.
I before as well. Just keep that little path. Yeah, persistent path. Otherwise it's such a pain in the butt.
And it is a cause of stress because you do you forget that it changes in the dust. You can also host your own version of these, but then you're thinking at least five bucks a month for a VPN or VPS, which is almost the cost of end rock per month. So you might as well just let them do it and figure out all the natural for soul and fire walls and all that pain in the butt stuff. Yeah, I've worked with work, please.
Other stuff I've done in the past is I have replicated the requests in something like insomnia or postman or something like that. I specifically use insomnia and what it's on the is a little bit. that's not that you can download and you can save common requests. So I've got little like a snip cart order doc completed web hook.
And it's being a local host, seven, seven, seven, four, eight, four, and then I have the JSON body. And that's just a test web hook that I can rerun over and over and over again. And then I can work on my local development server. And that's really nice because if you're in the middle of a, you save, retry it, save, retry it, save retry it.
It's kind of annoying to go back to the service and retrigger one. So if you just replicate what that web hook looks like in insomnia or postman's another popular one, there's all kinds of them out there. Yeah, it's great because you can just save pretty common ones. You can share them with users.
You can change off headers. You can change the post. You can set cookies that gets along with the request. I find this to be really, really handy for debugging and working on both web hooks as well as just regular rest APIs and not specifically just web hooks.
Yeah. Yeah. Yeah. Yeah.
Yeah. It's like it's probably one of the most pain in the butt things to work on is debugging my post. Yes. And just put that all in your editor.
So there's a, if you go to extension that will allow you to trigger and generate common scenarios of things like credit, reject it or something like that. It's especially when you need to test over and over again. You're typically going to like a web URL clicking a button checking to see if it came incorrectly doing the right thing out of the video. It's not one of those things.
It's easy to wrap it test. I should also say with the insomnia approach, what I'll usually do is go into my, that handler or my endpoint handler. And when the event comes in, I will just either console log or write the body of the request to a JSON file on my computer and then have an example of what an entire request looks like. You can also usually go into SIM card or whatever and just copy out the body because it will show you exactly all the data that it's sent over.
What else we got here? I think that's just about it. I asked them to whatever any tips that people have someone said webhook.site is really good for testing. It looks very similar to, oh, no, this is sort of the opposite and is that you can ping webhook.site with an unique URL.
I'm going to see what data comes in. A lot of people says make sure you use ngrock things like that. Like these tools, look at that site. It's something I would use to verify the data correctly.
Sometimes you need to test that webhook. You just want to see exactly what that is coming for the services and there's no great documentation or anything like that. So that's great. Or if you're just going service to service, right?
Like if you're using someone said n8n.io. It's like an extendable workflow automation tool. What's the one that runs with this and that, right? A lot of these loco no code solutions is or Zapier.
That's another really good one. Where you take an incoming request, you do a little bit of something to it and then you send it off to another service. So if you're just streaming services together, you sometimes do not just running over yourself and you need someone in between. So it's another good example.
Someone said expose dev is a good solution similar to ngrock, which is PHP. So if you're using PHP, that's good. I use this with other stuff. Yeah.
Beautiful website. Well code. No code. I'll dig in.
I'll tell that one in. I want to do that earlier. I don't interrupt you. I think that's all we have to say about webhooks.
They're pretty simple things. It's sound much more interesting than they are. They're not even special. They're just HTTP callbacks.
We can call them. Yeah. It's a request. It happens from a place in other places except it's an input.
Easy, easy. All right. Thanks very much for tuning in. We'll get you on with a piece.
And on over to syntax.fm for a full like I have all of our shows. And don't forget to subscribe to your podcast player or drop a review if you like this show.