Restful webhook using Lambda + API Gateway — PART 3
If you have been following the series (Part 1 and Part 2); so far we have established a Lambda based Flask App that handles GET and POST requests. We then configured API Gateway to route suitable requests to the Lambda along with error handling methods.
In our quest to create this:
We have most of the pieces in place except for the introduction of the actual source; In this case GitHub Webhook. GithHub will now take the spot of postman in our dig:
webhook! Whats this now?
A webhook allows us to build integrations which subscribes to specific events that occur on the source system (GitHub is the source here).
Event: An Event could be a commit, a deletion or even a push made against a Branch. GitHub allows you to configure which event would be counted as a trigger.
Once this so called event occurs; GitHub then sends a POST Payload to a URL that we provide to them. GitHub will essentially make a POST request against our URL and send us details of the event. Once this request enters our AWS Environment, API Gateway then reroutes the request to our Lambda which then determines the business logic that needs to be applied.
Here, our lambda will simple extract the name of the author that triggered the event and send it back to GutHub.
webhook setup
For the purposes of demonstration I created a dummy Repository on github and will be interested in the Push event.
Head over to your github repository which you wish to track:
In the Settings section select Webhooks:
Since we are doing this for the first time, it is obvious that this section will look barren. Add webhook feature would thus be a good place to create a trigger.
Thanks to GitHub; the wizard to set up a trigger is fairly simple.
Go ahead and paste the URL we generated at the end of our Part 2 article. This URL needs to be added to the Payload URL section.
Settings at a glance:
Content-Type: Since you will be interacting using JSON objects, select application/json
Secret: This would be applicable if you wish GitHub to use a credential to interact with your URL that will be authenticated by API Gateway. We wish to have No Auth configuration which allows anybody to access our URL.
Note: The No Auth setup is adequate for Testing and development purposes only. This route is not recommended for Prod systems.
SSL Verification: It is recommended to have this option enabled but I have it disabled for this walk through.
Events that will trigger the webhook: This tells GitHub as to which events your webhook is interested in. While you can select the type of events; I have chosen to go with Push event.
Go ahead and save these settings and prepare to make a push from your local git repository to your remote.
Trigger the Webhook
A Push event is what it takes to trigger our pipeline so we will go ahead and push a change to our remote.
Head over to your GitHub webhook form and scroll down to see a list of events that might have occurred.
Recent Deliveries section lists all the payloads that have been sent based on how many times you make a Push to your remote repository.
Click on the most recent event which should look as such:
Notice the Body section of your Response; It should contain the name of the author who made the Push as well as your custom message.
Viola! Your AWS setup will now be in reactive mode in response to any events that occur on GitHub.
For Future Exploration:
If you have reached this section then You must be enthusiastic!! Such Enthusiasm will help you to explore and enhance this skeleton that we just created.
Here are some ideas you could implement to increase the capabilities of your webhook:
- Configure GitHub webhook to subscribe to other events.
- Configure your lambda to handle the myriad of events that GitHub allows.
- Have Lambda log these events in dynamodb or RDS for analysis.
