How to Implement a Serverless Webhook
In your developer experience, you had to interact with external APIs through Webhooks. So you had to configure an endpoint able to receive HTTP requests from a 3rd party company and interact with your internal systems.
Using Serverless, you can implement the perfect webhook to integrate into your application. Which features need a webhook to be considered a good webhook? Let’s dig into it.
If you prefer to watch a video of me explaining how to create a full Serverless Webhook endpoint with AWS, click the below video:
Webhook? Tell me something more
A webhook is an HTTP endpoint that is called by an external service to notify your service about an event. Your application can react in different ways such as logging, sending a notification to your customers or calling an internal service.
While developing the solution with Serverless services, I will keep in mind the following concepts with the relative AWS services:
- Separation of concerns: our webhook should keep the acknowledge and the processing of the message in two different boxes, meaning that it should notify the service with a successful response as soon as possible and then focus on processing the message. AWS Service: API Gateway + Lamba
- Monitoring: the webhook should have a monitoring system that notifies your application of any excessive amount of notification or a wrong configuration of the secret used to check notification signature. AWS Service: CloudWatch
- Asynchronous decoupling and errors management: A decoupling service (like a queue or an event manager) should be implemented between the acknowledging and the processing workloads. AWS Service: SQS or EventBridge + DLQ (for error handling)
Keeping in mind the above concepts, I will explain two different architectures using only Serverless services.
Architecture 1: Lambda + SQS
Starting with the API Gateway to expose our public endpoint is the logic and natural choice for our webhook. The API Gateway gives the flexibility to add an authorizer function (if needed) and to add a validator to parse the request. Then, we can add as the backend service of the API Gateway a simple Queue with AWS SQS. The queue is the trigger of a Lambda function which will consume messages and reply back to the 3rd party service. The scope of the lambda depends on your application. It can add an entry on a database (DynamoDB, RDS), it can call an SNS Topic or save a log entry in S3. Notice also the DLQ configured to handle errors in the Lambda function.
This design ensures the separation of concerns with the decouple service being SQS and the processing service being Lambda. It implements monitoring with Cloudwatch and an authorizer function directly in the API Gateway.
Architecture 2: Lambda + EventBridge
The above design is similar to the previous one but it has AWS EventBridge as the decouple service. Using EventBridge, you can call different lambda functions based on the filter implemented. I believe this is a more scalable approach if you want to add or remove services in the future.
Conclusion
Wrapping up, in this blog post I broke down the concepts of a webhook and proposed two different architectures to implement a complete Serverless webhook in AWS.
Let me know what you think in the comments. Follow me on Twitter and Youtube for more!
