Automating Business Logic with Hasura Event Triggers and AWS Lambda

Here at Antematter, we have a very special relationship with Hasura. We’re now using it on two long-term client projects. And sure, while we realize that there might be better options out there, Hasura has treated us well and we’ve therefore continued to stick with it.

?? For some context, Hasura is a backend-as-a-service platform that provides us with an instant GraphQL API on top of popular databases.

Hasura has allowed us to focus on actually pushing out new features instead of worrying about managing the underlying infrastructure. As we continue to discover new ways to use it and solve business problems, we’ll continue sharing them here.

The Problem

The problem is simple: we need to be able to run custom business logic reliably after a specific type of event. A classic example is sending a welcome email after a new user signs up on your application. We’ll continue to stick with this example moving forward.

As such, here’s what a simple schema for our user table might look like:

Now, we want to send a new user a welcome email after they’ve verified their email. To keep things straightforward, we can ignore the actual email verification logic for now and simply assume that the email_verified field will be set to true whenever this occurs.

An Easy Solution

As you can imagine, there are several different solutions to the problem at hand. With Hasura, the solution is incredibly simple:

1. Create a webhook using Hasura which is triggered whenever the email_verified field is updated.
2. Configure an associated Lambda function that is capable of sending out a welcome email.

We’re not going to go into the specifics of setting up Hasura itself (or AWS, for that matter), since the documentation covers all that in detail. Instead, we’re going to walk through the two steps mentioned above — short and simple.

Step 1: Creating a Webhook Using Hasura

The first step is to open the Hasura Console and head to the Events tab. We’ll start by creating a new event trigger.

After assigning our event trigger a name and selecting the underlying table (user in this case), we can start configuring the event trigger’s properties. For starters, we want the event to be triggered on Update operations on the selected user table. Additionally, we only want the event to be triggered when the email_verified field is updated

.We’re going to add a dummy value to our webhook handler URL for now, since we haven’t set up the associated Lambda function yet.

Now, if we click on the Advanced Settings dropdown, we’re presented with two additional options: the retry logic (which lets us customize the webhook’s retry behavior in the event of a failure) and the headers. Ideally, we’re going to want to add a header (called TRIGGER_SECRET or something similar) and assign it a secret value that we can verify in our Lambda function (to ensure that the incoming request is valid)

.Next, we can optionally modify the outgoing request itself (in terms of the method and query params) and transform the body as well. This is useful when you want to enforce a specific format across your event triggers. We’ll skip this for now and stick with the default settings

.With our event trigger created, we can now start working on the associated Lambda function.

Step 2: Configuring Our Lambda Function

After creating a new Lambda function using the AWS Console (and modifying any required configuration options such as the timeout), we can write some simple code to process the incoming request from the event trigger.

The first step is to verify the incoming TRIGGER_SECRET header (against the TRIGGER_SECRET that we’ll add in the Lambda function’s environment variables):

The next step is to parse the request’s body. Hasura has a default structure for the payload that is sent when an event trigger is invoked. In our case, this payload will look a little something like this:

{
	...,
	"event": {
		"data": {
			"new": {
				"id": 123,
				"first_name": "John",
				"last_name": "Doe",
				"email": "[email protected]",
				"email_verified": true
			}, 
			"old": {
				"id": 123,
				"first_name": "John",
				"last_name": "Doe",
				"email": "[email protected]",
				"email_verified": false
			}
		}
	}, 
	...
}
        

This payload will vary based on the event trigger’s operation type. For Insert operations, event.data.old will be null. For Delete operations, event.data.new will be null. In the Update case that we have above, event.data.old and event.data.new will contain the values before and after the update respectively.

All that we need to do now is check whether the email_verified field is true (as a precaution) and send a welcome email:

Once you’ve deployed your Lambda function, all that’s left to do is create an endpoint using the Amazon API Gateway service so that our event trigger can communicate with our Lambda function. We can use the AWS Console to create an HTTP API with a single POST route and attach it to our Lambda function. Then, all we need to do is copy the Invoke URL and update the webhook handler URL for the event trigger in Hasura (which we had added a dummy value for previously).

And with that, we’re done. We can test our event trigger by adding a dummy row in our table and updating the value of the email_verified field to true:

It really does not get any easier than this.

Closing Remarks

The purpose of this walkthrough was to demonstrate just how easy automation is with Hasura Event Triggers. There’s no complicated configuration or setup, which means that it’s incredibly easy to create multiple event triggers and combine them with multiple Lambda functions for a truly server-less experience.

This article is written by Zohaib Adnan , Full Stack Developer at Antematter .