>> Good morning.
Hello.
My name is Lorna.
I'm an IBM developer advocate in the cloud data services division.
I've been in my job three weeks, that's the first time I've ever said that on stage.
I'm here because I'm really excited about webhooks.
And actually you're excited about webhooks as well.
You are seeing them in many places.
The classic example is the notifications that you get in your chat channels.
I know Slack is the cool thing these days.
But I am also a fan of IRC, I'm using it in all of my open source projects, I'm using
a hue bit and bringing it into the conversations where the humans are.
Webhooks is all about moving data.
It's about getting data from one place to another.
And maybe you think I'm describing an API here.
Well, let's go look at APIs first.
APIs work like this.
The client asks the server for data.
Please may have some data?
And it's always that polite.
And the server says here's your data.
Unless there isn't any, in which case the server says nope.
In comparison, webhooks work the other way.
The server starts the conversation and kind of arrives with a ta-da, here is some data.
And this client responds thanks with a smiley.
In HTTP, we spell the smiley is, like, a 200.
You can think of it as a smiley.
And that's cool but we've seen that those little interactions Euro isolation.
So we're admitting something really important, which is how does this work over time?
Many software inventions work brilliantly well until you consider what happens to them
over time.
And this is no exception.
So let's consider these over time, starting with APIs time running left to right for you.
First of all, the client makes an API called the server and says may have some data, and
the server says nope.
And some time later may have some data inspect and the server says, oh, yeah, here's some
data.
And later it says may have some data?
And the server says nope, and you get the picture; right?
This is just a whole lot of nope goes on with chattering.
Nothing is really happening.
There are some adaptations in this pattern, which improve it.
So we'll sometimes keep that connection open for a while.
So if you have the need to send quite a lot of data, like, quite regularly.
If you're going to do lots and lots of sends, it's worth to keep that network open.
It depends on the shape of your communication because often if it's the occasional ping
only when you say let's say release to master, then we probably don't want to hold a connection
open for that.
Compare that to what happens with the same thing in the webhooks.
The only conversation that happens here is the service sends the data and the client
sends back the thank you and the smiley.
It's much less chatter, but we're still achieving the same thing.
The big difference here is that we have to do some prearrangement to make this happen.
The server already knows where to send that data to.
The -- in the API model, the client can just access the API.
Yeah, maybe there's some sign up, maybe upper back to authenticate, something like that.
But there isn't the same level of prearrangement that we have with webhooks, so you need to
set this up in advance.
This is a screenshot that you may or may not be able to read from GitHub signer.
And the information GitHub asks for, give a really good example of webhooks.
I love the way they implement theirs.
They ask you for a few key pieces of information.
They ask you for the end point you would like the data to go to.
So where the post of the webhook payload should end up.
On development machines, this can be hard.
They're only letting me talk for ten minutes, so ask me about that over lunch.
There's an API, most hooks are JSON, you can get a choice, a form post.
Also a secret, which is another thing I like about GitHub.
Webhooks in general can be a little bit Internet of things in their approach to security.
And therefore GitHub gives you the opportunity to enter a secret here and then check if that
secret arrives at the payload.
So you can filter out things that would otherwise deny your service at your service.
Also get a choice of what events you want to subscribe to.
GitHub makes it easy, you can have push commit or everything.
And then this is sounding familiar you subscribe and that information sends to you.
Yes, I am subscribing hub over HTTP, that's all webhooks are, and they are super cool.
Let's drill into a webhook.
I have this great idea that I would pick the smallest webhook that GitHub sends.
Put it on the screen, and walk you through it.
And I got this, which is creating a wiki page.
Relatively small but relative to everything else.
Only 111 on the one side.
I'm not to fitting my size to the screen.
So let me give you an overview.
This webhook, there's a new page on the wiki, I am notifying you it of.
It includes information of the page, the repository it's in, the owner of that repository, so
it can be a user or in the accident of.
And also the user who did this action.
There's a lot -- theres a lot of hypermedia here so a lot of end points where you can
get more information about any one of these things.
But as you can guess from the 111 and more lines, it's fairly verbose.
Maybe you test it with 1,000 users, you've got a million users, you webhook something
to them with a very minimal payload, collection of users and only use hypermedia.
Any one of those million subscribers immediately calls back an API request for every user in
the collection.
You just caused your own problem.
So that is why the webhook payloads are verbose.
Also normally use these between servers, so we're not so worried about the size of the
data that we send as we would be in perhaps mobile.
Here's the owner chunk.
So it's not even the whole.
It's most of it.
And you can see from this I've got the user's log in, so I can display the display name.
I've got a link to the avatar and also got as well as the URL, which is call this API
end point to get all the user data.
I've got their HTML URL.
So I can link to their GitHub page.
I can splay this in a user friendly way.
This is all the information I need.
On the other end if you're receiving these webhooks, there are a few tips that I would
like to share.
When you're receiving webhooks, do not get it while you process the in coming webhook.
Make sure you've got it, stored it, and then just send that smiley.
Get it, store it, back it.
Probably put it in a queue, process later.
But don't try to validate and mess with things as they come inspect.
Just accept and store and that gives you the ability then to scale your system to retry
or validate or whatever you need for your use case.
That's just a little tip from some things I may or may not have done wrong in the past.
The Web hooks, the APIs, these are what wire our world together.
We expect particularly our hosted tools to talk to one another.
This is how we glue our workflows together.
We don't buy in with a single group ware that does everything.
We just pick and choose the best tools and put them together and most of the time we
don't need to work with code.
I've given you advice if you're building this yourself, publishing yourself, receiving yourself,
you don't need to write code for this.
One of my favorite tools is Zapier and what that does is allow you to wire tools together,
so you can respond to it with another response.
So maybe a new e-mail arrives in support to a e-mail in-box.
You can create a Zapier, the marketing department thought hard about that I'm sure.
You can zap the new e-mail and turn it into a ticket in your bug tracker.
Maybe the developers would rather use GitHub issues but the project managers would rather
use base camp.
You can set up zaps to keep those in sync or put important information across between
the two.
This all works in webhooks when you commit and your build server responds, it's all about
webhooks.
Webhooks are quite frankly awesome.
I love them.
I hope that you love them a little bit more now too.
Thanks for listening.
[Applause]