 So, our next speaker, I don't know if she still needs an introduction, but it's Lorna Mitchell. She's done, well, a lot of conferences, a lot of talks. We're quite happy that she's here. And she will talk or learn everything about the weapons. So, oh no, make us learn everything about the weapons. Awesome, thank you. Let me tell you, let me tell you that he is not as excited about having me here as I am excited about being here. Like, yay, it's faster. There's a PHP room and they're letting me in. Everything is good. Cool. So, hi, I'm Lorna. I'm a developer advocate. My background is PHP development. I have been giving talks at PHP conferences for more years than I'm going to tell you. I'm currently working at Nexmo. Nexmo are, we do telephony APIs. So, if you have an app that needs to send a message, SMS, Facebook, WhatsApp, if you need to make a call, make a video call, these are the people you should talk to. I understand their PHP tech support is pretty good. So, one of the things that I come up against when I'm doing my developer advocacy job and helping developers work with APIs, particularly APIs like ours, is that you have to be able to handle incoming webhooks. So, something happens, maybe somebody is calling you, there's an event on during a phone call, maybe you receive an SMS. Those will give you an incoming web request, a webhook, and you need to know how to handle that. So, I think this is a really important topic for developers and one that sometimes just trips people up. It's funny because you know how to handle webhooks. It's just an HTTP request. PHP is all about solving the web problem. We know how to handle incoming web requests. When we call them something different, it can be a bit unnerving. I've put here, it's an HTTP post request. We'll skate over the post part because quite a lot of the next-mo ones are get for historical reasons, but typically you'll see a post with a JSON payload coming in. Why webhooks? Well, I think these are becoming much, much more common in our applications as we start to integrate applications with each other. And it might be that you're integrating your application with a third party. Once upon a time, it was acceptable to send an XML batch import overnight, maybe a CSV file. We don't do that anymore. We teach the machines to talk amongst themselves, and webhooks is part of that protocol. When you can support webhooks, you can react to events in other systems. If your application is made of components, maybe those events are being communicated between parts of the same system. I noticed this year that not every conference talk has microservices in the title, but this is the kind of tech that we're building on. The most important thing I want to tell you about webhooks is you're already familiar with them, whether you know it or not. If you have a bot in channel that lets you know when things happen on GitHub, when you open a pull request and things happen, this was one of mine, things went wrong, and things happen, that is all done with webhooks. You push your code to GitHub, GitHub sends a webhook to Travis. Travis trunters away, puts it in the queue, eventually processes the build, and sends the result back to GitHub by another webhook saying, hey, that pull request you sent me, it was rubbish. Here is the status, here is the link to the log, and so on. So those payloads are all webhooks. We work with this stuff all the time. We use them to notify one system of an event in another system. We use them to ship data because data is available. We can also use webhooks to communicate to potentially many receivers. So it's not like when this happens, I do this. Interested parties can subscribe to receive a webhook in response to an event. So it can be quite published, subscribed, quite broadcast. Let's take a step back and recap on how APIs work, so you can think a little bit more about how webhooks are different and how they're the same. How APIs work, this is the client. The client asks the server for some data, and the server says, here is your data. Unless there isn't any, in which case the server says nope. Webhooks look really similar, except that the data comes in from the server when there is some data, the server just sends it over to the client. The client says thanks with a smiley. In HTTP, we spell the smiley like 200 okay. But you can think of it as a smiley. Like most good ideas in software, this is great until you consider what happens when you start doing that over and over again over time. So this is flipping the graph around completely to confuse everybody. We're just going left to right, but the client and server are now in different places. The client asks the server for some data, and there isn't any. The client asks the server for some data, and we do get some. The client asks the server for some data, and there isn't any, right? This is polling. This is all network chatter. Compare this with how it looks for webhooks. There is some data. We send the data. The client says thanks and we're done. We have a lot of questions. That GitHub are king of webhooks because if you think of every repo you've ever pushed to GitHub, every continuous integration server you've ever set up, how many, and if every one of those repositories was being pinged by every one of those servers every 10 seconds or every minute, we used to wait a minute for builds. It seems crazy now. like half the internet traffic in the world. I wouldn't want to run those servers. And neither does GitHub. So instead, we use this event-driven setup where we only send data when stuff happens. This bunny is here to remind me to breathe. It's our fluffy animal moment. And try and break things up before I talk about the next section. What's interesting about webhooks is, when you call an API, you know where the API is, right? You have the URL. And the client just decides, I would like to get some information from there. And maybe you need to sign up for some credentials. But essentially, you make a request, and that's it. With webhooks, you have to set that up in advance. The server needs to know where to webhook to. Needs to know that you're interested, what you're interested in. And we have to make that agreement beforehand. So the client has to subscribe to events. If you set up a webhook on GitHub, you'll get asked, where should we webhook to? You give the URL of the client the exact path that it should webhook to. You get asked about whether you want it in JSON or HTTP post format. You can choose which events you want to subscribe to. And then when those events happen, you'll get that format posted to that URL. That's how that works. But we have to set it up in advance. And that's a big difference. I want to talk about how you receive those webhooks in your code. Warning, we're going to do a minor tangent, so I can tell you the tools that you need to really receive them in your code. And then we'll do a bit more theory. I want to introduce you to a tool called ngrok. ngrok is a secure tunnel to your dev platform. Basically, you run this program on your machine where your development code lives. And it makes a public URL on the internet able to reach the code that's running on your machine. This is because the webhook server needs to be able to reach your code. And you can push it to the cloud every single time you change the file if you want to. I am too impatient for that. You can use this tool to allow your dev code to be reachable from a public URL. I also use it for all kinds of stuff. If you have a website running locally and you want someone else to take a look at it, fire up an ngrok tunnel, give them the URL. They can access your dev platform. If you want to see how the site looks on mobile, just quick check, different platform, same thing. That's what I use it for. So it's crucial for webhooks. But actually, this is a tool that you probably use in day-to-day web development. So it allows the webhook to reach your local code. But it has some extra features. With ngrok, you get like a web dashboard. You can see the details of the request that arrived, or everything, the headers, the body. You can also see the response that your code sent. And both those things can be really helpful for debugging. You can replay the requests and see the responses. This is really important, because if you're doing an edge case like somebody commented on a pull request, if you want to test that webhook, you've got to comment, comment, comment, comment. Keep making the event happen. If you're coming through ngrok, you've only got to replicate it once. And then you can just hit the replay button and keep editing your code, replay, and keep editing the code. So I think that's really, really useful. So you run the program on your laptop. It gives you a public URL. When there's a request comes into that URL, it hits ngrok servers, and they send the tunnel through to the application of theirs that you're running on your laptop. It is secure, but try not to leave them up and running. Not recommended. Cool. So I thought it would be really good fun to try and show this to you really quickly. And we can agree afterwards whether it was a good idea or not. So I work for Nexmo. We do SMS. What we're going to do is I'm going to buy a phone number. I'm going to send a message to it. And I'm going to show you how to receive that in PHP. So I've written myself a note that says you need to marry your screens. That's good. I did that. Cool. If you want to play along, you need to be super quick, and you need the Nexmo CLI command line tool. OK. Oh, yeah. Major disclaimer. I hope you're going. This is why I wrote instructions. Major disclaimer. Two major disclaimers. The first one is if you text this number, your number might be visible in my logs on the screen. And secondly, if I see any content I think could offend anybody in the room, the demo stops immediately. So choose carefully what you send. All right. Not that I've had problems with other audiences before, but it could happen. So we're going to buy a number. So let's start with, I'm going to buy a British number. I'm sorry. Belgium has like, oh, I'm not on the internet. That's not going to work very well. Let's just hit the, I wonder if I can get connected for a quick go. Smooth as. Belgium has more rules about who's allowed to send nonsense to your phone, which seems like a good thing except it's not so great for when you're trying to run demos. That didn't connect. Yeah, I probably can't get an IP address at this stage. I'm just going to hotspot quickly and see if that gets us up. Otherwise, you're going to get MIM instead of demo, which won't be as much fun, but we'll give it a try. So all I'm doing here is searching for a number. And then when I get a number, I might choose to buy it. OK, well, let's see if that connects, but I'll just keep talking. That's fine. So you buy a number. When you buy a number, you can then send, like literally I'm just going to send a text to it from my phone. And when that text message arrives, what happens is it's next-mode owned that number. So the text message arrives on next-mode's servers, and next-mode will send a webhook to the URL that you've configured. So you buy the number, and then you say, when you get a text to this number, you're going to call this URL endpoint. And we could set up Ngrok to try that. Oh, this says it's online. Mail may not go well. There we go, cool. Let's have a number. I like this one. Next-mode number, buy. I want this one, please. Yes, spend my money. So we've got a number. And we're going to need this number later. I've had it in my copy-paste buffer, so that's fine. Next, I'm going to write some PHP code. And we're going to call it hook.php. And all I'm going to do here is literally dump the incoming request object. I'm going to dump it to Errolog because you can see that when I'm running it local host from the command line. Did you know that you could return a second parameter from print R to get a nice output that you could Errolog? Now you did. Cool, so we've got hooked up PHP. And I'm going to serve that like this on port 8080. Lovely. Let's have a new window. So we can check that our code is doing what we think it should be doing by making a web request to it. This is local host. That's not local host. This is why you should never demo live. This is local host. And it is hook.php. And since this is a PHP conference, we'll use the typical fruit example that we love in our documentation. And then you can see that we just dumped the request object. This green line is the log that the built-in server gives you anyway when it's running. Cool. So we've talked about ngrok. Let's have a bit of that ngrok. HTTP port 8080. Gosh, this is huge. Sorry. I'm looking for a middle ground where you can sort of read it. How's that going at the back? Yeah, Andreas is nodding. Thank you. Cool. So you get this random URL. We're going to use the HTTPS1 because we're very security conscious. And when you request that URL, it is going to map through to this local host 8080. So I can make a request maybe from my browser with that URL slash hook.php. And just to prove that things are different, we'll pick a different fruit this time. Oh, gosh. Yay. And if we go back and look, we can see we've got a response. It also requested the fav icon because I use my browser and this doesn't serve one. So oh well. Cool. So now I've got a working webhook endpoint. I'm going to link it to that Nexmo number that I bought before. Yet another window. Come on. I need a separate console setup to make these bigger things. Right. So we're going to go Nexmo. Where's my instructions? Here we go. I'm going to link the Nexmo number to the URL that we've got. So let's, that's probably not still my copy-paste buffer, so let's, that's the number, yes. And then this is the URL, yes. And we're going to do hook.php on the end. So when an SMS comes into this number, then a web request is going to come through to that URL that you've just seen work. So I just requested it from my browser. Excellent. Now I'm going to cheat Nexmo SMS number, which is still not the last thing in my copy-paste buffer. Who invented this thing? I contribute to the CLI. Great. Confirm. Yes. Yes, please send a text. So we sent ourselves a text. Let's have a look at something arrived. Something did arrive. I've got a 200 OK. So this is a list of the requests. And if we have a quick look at what's running here, that's what came in. So all these parameters came in that show us some stuff. Yes, I'm running a public NROC on a live demo. Yes. Cool. Excellent. So one of the features that I really want to show you on NROC, before I get so stressed that I shut down, shut that down, from running an open NROC in the middle of a demo, is this. So this first one that I think is, oh, where's my request to hook.php? There it is. This is my request to hook.php, unlike all the other ones that are coming in from the room. So you can see here, there's all of this data that came in, gets passed for us. These are query parameters. And if I had sent a response, you'd be able to see it. When you're working on receiving web hooks and you want to iterate on the code that's here, I don't need to send myself another message and incur another charge to test it. I can just use this replay button here, which will just skip over because I feel like my traffic's getting lost in the noise from the room. But you can keep using that replay traffic. So I can literally go back, edit hook.php, the local running server will just pick that up. And I can just replay, replay, replay, maybe even echo or var dump some debug stuff while I'm working on it. And once I'm happy, then send another web hook through from Nextmo. So that's the basic idea that you just need to have a local server. I am so stopping my Ngrok server now. Cool, thanks. Like it is crazy to run a local demo. I know. So the whole point there is that you've got local server responding to incoming requests. All of you probably write in different frameworks. So you don't write a plain old PHP file like that. But all of you can understand it and see what happened there. So whether you're a Laravel user, a symphony user, slim PHP, cake PHP, probably forgot some really important ones, sorry. You're going to register a route and then have a look at those incoming parameters and react however you need to react to that incoming message. Maybe send a message back to the user or handle it whatever your application needs are. I shouldn't have shut that down. One really important thing that I wanted to mention, there's my slides. There we are. I am running open endpoints on the internet. You just saw what happens when you do that. So is that cool? No, not really. Using HTTPS is fine, but you do need to be aware of security when you do this. For the most part, most of the problems that I see with open webhook endpoints on the internet are not malicious. Usually it is just an internet of things sensor gone mad and run away and just accidentally sending too much data or to the wrong place or your system chokes because there's a new field and you weren't handling it. It isn't usually malicious, but it could be. So be aware of the attack vectors. You are web developers. You know how to do rate limiting. You know that you must always use SSL. For Nexmo, we have shared secrets. So what you see here is in addition to just the text and stuff that comes in, Nexmo has a signature secret that I also have. It is not transmitted with the packet. So in Nexmo sending me the message, it concatenates all of the fields and their values together and my signature and creates a hash. That's what's in the SIG file here, in the SIG value here. So I also have that separate signature, which isn't in the packet. And I can reconstruct that signature and compare them. They are the same. If anyone had changed any part of this, the timestamp value for a replay attack or change the content of the message, that signature would not check out. It's not enabled by default on Nexmo. I hope you all become Nexmo users. In which case, immediately email support. Tell them to turn it on. The PHP library has the built-in signature checking. There is no excuse for this. If you're handling webhooks from other providers, like I hope that you'll handle all the webhooks for all of the things in all of your amazing applications. But you should be looking for where's the signature? How can I verify the origin? Because you are trusting data that is coming into your endpoint. So just take it easy. Security is still a thing. Even if you are dealing with internet of things, security is still a thing. Please bear it in mind and think carefully about how things should work. For the Nexmo signature, it just looks like this. Install the PHP library from Composer. Pass your signature and the incoming parameters to construct this client's signature object and then pass in the signature that came in from the request. And that is it. You can all do this. No excuses. I don't want you to get bad data and trust it. Webhooks are fabulous. You might hear them called async APIs or there's a bunch of different ways they get referred to. But allowing that asynchronous communication, just HTTP applications, different machines, is whispering to each other. And exchanging data, there's a lot that we can do with this. If you're not already working with this stuff, I expect you to be. Hopefully this has made it a little bit easier. And hopefully it's giving you some ideas of when you might want to implement it. Use your webhooks when you want to notify another application. Remember that you need to do that setup step first. So people need to be able to register with you. And then you know, all these people, I need to let know when a commit comes in or a message comes in. You've got subscribers. If you're familiar with the published subscribe pattern, yes, it smells familiar. That's exactly what it is. Hopefully these examples of how to use webhooks give you some ideas. I see a lot of APIs that give you a later callback. So you ask for something to happen and when the result is ready, you receive a callback. Exactly it's all going to look like this. You're going to evaluate that incoming request and use the data that arrives. You're PHP developers. It's HTTP. This is absolutely in your wheelhouse. If you hear these words and they seem unfamiliar, go, yeah, I can do that because you can, right? There's going to be no problems here. I am going to wrap up. I just have a few resources for you. Check out nextmo.com. You get a couple of euros credit anyway, so you should be able to do the demo that I've showed you without having to talk to us. DM me on Twitter if you would like more credit. I can do that for you. That's me, lonajane.net, and at lonajane on Twitter. I would be delighted to hear from you and answer your questions. I mentioned Engrock as a really cool tool, so that's a link to that. And PHP Web Services, I have been to visit O'Reilly, who are downstairs in Hblock. They did earlier have some copies of PHP Web Services, but Helen Thomas, she's already sold a couple. So if you want the book, it's not brand new PHP. It's a couple years old now, but nothing's changed and it's got a lot of web theory. Then go and see Helen and get the hard copy and hopefully that'll be helpful to you. Do I have time for questions? Not really, yeah. I can take a couple. Does anyone have questions? I might not need to, yes? Where is the difference line between web books and Web So this question is, what's the difference between web hooks and web sockets? So a web hook is just a one-off request. So we send the request, you should immediately acknowledge an incoming web hook, which is perhaps something that I didn't make clear enough. And then we close that immediately. Whereas a web socket, you open the socket and then communication continues over that open socket over the time. I see a lot of use cases where you have some choices between polling, web sockets, so hold it open and chat as it happens. Or web hooks would be an alternative approach. Tend to use web hooks when it's lower traffic so I don't want to hold that connection open. If you've got lots and lots of chatter, a web socket might be a better choice. That was a really good question. Thank you. I could probably take one more. OK, I can take a few more. There we go. Well, that is a world first. If that talk is shorter than the slide I was given, that would be unheard of. No, they're going to let me off really easy. OK, in that case, I'll just say thanks very much. Feel free to come and chat.