AWS AppSync adds quick-start sample for Amazon Aurora

AWS AppSync has support for a wide variety of data storage options—including Amazon DynamoDB, Amazon ElasticSearch Service, and AWS Lambda.  Today, we’re announcing the availability of a quick-start that connects to Amazon Aurora MySQL mode using AWS Lambda.  You create this connection using a Lambda function that executes a SQL statement (provided by an AWS AppSync resolver) on an Amazon Aurora database.

You can easily provision a GraphQL schema for a sample blog using Amazon Aurora directly from the AWS AppSync console:

The sample schema creates a combined architecture consisting of AWS AppSync with Amazon Cognito user pools, an AWS Lambda function, and an Amazon Aurora MySQL database running on a t2.medium instance.  The sample schema provides posts and comments, with standard operations for each table that may be used to generate a small blog site.

If you wish to connect your own GraphQL schema to an existing Amazon Aurora database, then use the following instructions:

1. Create an AWS Lambda function based on the code provided in our GitHub repository.
2. Update the code so that the appropriate database schema is created when the database has not been configured.  This should match your AWS AppSync schema.  You can find the appropriate code at lines 28 through 61 of the script.  If you already have a schema, just comment out the appropriate create method calls.
3. Within the AWS Lambda function, set the following environment variables:
   • USERNAME – the RDS username to access the database.
   • PASSWORD – the RDS password to access the database.
   • ENDPOINT – the endpoint address of the RDS cluster.
   • DBNAME – the name of the Aurora database.
4. Within the AWS Lambda function, provide any security settings necessary to connect to the database (for example, VPC settings).
5. Within the AWS AppSync service, add the AWS Lambda function as a data source.
6. For each query and mutation within the AWS AppSync schema, edit the resolver and set the request mapping to the following (as an example only):

   {
     "version": "2017-02-28",
     "operation": "Invoke",
     #set(id = $util.autoId())
     "payload": {
       "sql": "INSERT INTO table VALUES (:ID, :AUTHOR, :CONTENT)",
       "variableMapping": {
         ":ID": "$id",
         ":AUTHOR": "$context.identity.sub",
         ":CONTENT": "$context.arguments.content"
       },
       "responseSQL": "SELECT id, author, content FROM table id = '$id'"
     }
   }

7. Set the response mapping template to the following (as an example only):

   $util.toJson($context.result[0])

   Note that the AWS Lambda function will always return results as an array, even when only one result is expected.

A mutation (such as is illustrated here) can do a second SQL statement to retrieve the results of the mutation. The responseSQL field is optional. In the case of a query, just the SQL statement and the variable mapping is required.

You can also deploy the entire configuration using AWS CloudFormation. For an example of a CloudFormation template, see the GitHub repository.

As always, we would love to hear from you. Please file issues in the GitHub repository for this sample, or reach out to us on Stack Overflow or the AWS Forums.