Data sources are resources in your AWS account that GraphQL APIs can interact with. AWS AppSync supports a multitude of data sources like AWS Lambda, Amazon DynamoDB, relational databases (Amazon Aurora Serverless), Amazon OpenSearch Service, and HTTP endpoints. An AWS AppSync API can be configured to interact with multiple data sources, enabling you to aggregate data in a single location. AWS AppSync can use existing AWS resources from your account or provision DynamoDB tables on your behalf from a schema definition.
The following section will show you how to attach a data source to your GraphQL API.
Types of data sources
Now that you have created a schema in the AWS AppSync console, you can attach a data source to it. When you initially create an API, there's an option to provision an Amazon DynamoDB table during the creation of the predefined schema. However, we won't be covering that option in this section. You can see an example of this in the Launching a schema section.
Instead, we'll be looking at all of the data sources AWS AppSync supports. There are many factors that go into picking the right solution for your application. The sections below will provide some additional context for each data source. For general information about data sources, see Data sources.
Amazon DynamoDB
Amazon DynamoDB is one of AWS' main storage solutions for scalable applications. The core component of DynamoDB
is the table, which is simply a collection of data. You will typically
create tables based on entities like Book
or Author
. Table entry information is
stored as items, which are groups of fields that are unique to each entry.
A full item represents a row/record in the database. For example, an item for a Book
entry
might include title
and author
along with their values. The individual fields like
the title
and author
are called attributes, which
are akin to column values in relational databases.
As you can guess, tables will be used to store data from your application. AWS AppSync allows you to hook up
your DynamoDB tables to your GraphQL API to manipulate data. Take this use case
AWS Lambda
Lambda is an event-driven service that automatically builds the necessary resources to run code as a response to an event. Lambda uses functions, which are group statements containing the code, dependencies, and configurations for executing a resource. Functions automatically execute when they detect a trigger, a group of activities that invoke your function. A trigger could be anything like an application making an API call, an AWS service in your account spinning up a resource, etc. When triggered, functions will process events, which are JSON documents containing the data to modify.
Lambda is good for running code without having to provision the resources to run it. Take this use
casegetPost ( id: String ! ) : Post
,
getPostsByAuthor ( author: String ! ) : [ Post ]
), they use Lambda functions to process
inbound requests. Under Option 2: AWS AppSync with Lambda resolver, they use
the AWS AppSync service to maintain their schema and link a Lambda data source to one of the operations. When the
operation is called, Lambda interfaces with the Amazon RDS proxy to perform the business logic on the
database.
Amazon RDS
Amazon RDS lets you quickly build and configure relational databases. In Amazon RDS, you'll create a generic database instance that will serve as the isolated database environment in the cloud. In this instance, you'll use a DB engine, which is the actual RDBMS software (PostgreSQL, MySQL, etc.). The service offloads much of the backend work by providing scalability using AWS' infrastructure, security services such as patching and encryption, and lowered administrative costs for deployments.
Take the same use
case
Amazon EventBridge
In EventBridge, you'll create event buses, which are pipelines that receive events from services or applications you attach (the event source) and process them based on a set of rules. An event is some state change in an execution environment, while a rule is a set of filters for events. A rule follows an event pattern, or metadata of an event's state change (id, Region, account number, ARN(s), etc.). When an event matches the event pattern, EventBridge will send the event across the pipeline to the destination service (target) and trigger the action specified in the rule.
EventBridge is good for routing state-changing operations to some other service. Take this use case
None data sources
If you aren't planning on using a data source, you can set it to none
. A none
data source, while still explicitly categorized as a data source, isn't a storage medium. Typically, a
resolver will invoke one or more data sources at some point to process the request. However, there are
situations where you may not need to manipulate a data source. Setting the data source to none
will run the request, skip the data invocation step, then run the response.
Take the same use casenone
, which acts as a pass-through value with no data source invocation. The schema is then
populated with the data, which is sent out to subscribers.
OpenSearch
Amazon OpenSearch Service is a suite of tools to implement full-text searching, data visualization, and logging. You can use this service to query the structured data you've uploaded.
In this service, you'll create instances of OpenSearch. These are called nodes. In a node, you'll be adding at least one index. Indices conceptually are a bit like tables in relational databases. (However, OpenSearch isn't ACID compliant, so it shouldn't be used that way). You'll populate your index with data that you upload to the OpenSearch service. When your data is uploaded, it will be indexed in one or more shards that exist in the index. A shard is like a partition of your index that contains some of your data and can be queried separately from other shards. Once uploaded, your data will be structured as JSON files called documents. You can then query the node for data in the document.
HTTP endpoints
You can use HTTP endpoints as data sources. AWS AppSync can send requests to the endpoints with the relevant information like params and payload. The HTTP response will be exposed to the resolver, which will return the final response after it finishes its operation(s).
Adding a data source
If you created a data source, you can link it to the AWS AppSync service and, more specifically, the API.
-
Sign in to the AWS Management Console and open the AppSync console
. -
Choose your API in the Dashboard.
-
In the Sidebar, choose Data Sources.
-
-
Choose Create data source.
-
Give your data source a name. You can also give it a description, but that's optional.
-
Choose your Data source type.
-
For DynamoDB, you'll have to choose your Region, then the table in the Region. You can dictate interaction rules with your table by choosing to make a new generic table role or importing an existing role for the table. You can enable versioning, which can automatically create versions of data for each request when multiple clients are trying to update data at the same time. Versioning is used to keep and maintain multiple variants of data for conflict detection and resolution purposes. You can also enable automatic schema generation, which takes your data source and generates some of the CRUD,
List
, andQuery
operations needed to access it in your schema.For OpenSearch, you'll have to choose your Region, then the domain (cluster) in the Region. You can dictate interaction rules with your domain by choosing to make a new generic table role or importing an existing role for the table.
For Lambda, you'll have to choose your Region, then the ARN of the Lambda function in the Region. You can dictate interaction rules with your Lambda function by choosing to make a new generic table role or importing an existing role for the table.
For HTTP, you'll have to enter your HTTP endpoint.
For EventBridge, you'll have to choose your Region, then the event bus in the Region. You can dictate interaction rules with your event bus by choosing to make a new generic table role or importing an existing role for the table.
For RDS, you'll have to choose your Region, then the secret store (username and password), database name, and schema.
For none, you will add a data source with no actual data source. This is for handling resolvers locally rather than through an actual data source.
Note
If you're importing existing roles, they need a trust policy. For more information, see the IAM trust policy.
-
-
Choose Create.
Note
Alternatively, if you're creating a DynamoDB data source, you can go to the Schema page in the console, choose Create Resources at the top of the page, then fill out a predefined model to convert into a table. In this option, you will fill out or import the base type, configure the basic table data including the partition key, and review the schema changes.
IAM trust policy
If you’re using an existing IAM role for your data source, you need to grant that role the appropriate
permissions to perform operations on your AWS resource, such as PutItem
on an Amazon DynamoDB
table. You also need to modify the trust policy on that role to allow AWS AppSync to use it for resource
access as shown in the following example policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
You can also add conditions to your trust policy to limit access to the data source as desired.
Currently, SourceArn
and SourceAccount
keys can be used in these conditions. For
example, the following policy limits access to your data source to the account
123456789012
:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
Alternatively, you can limit access to a data source to a specific API, such as
abcdefghijklmnopq
, using the following policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
}
}
}
]
}
You can limit access to all AWS AppSync APIs from a specific region, such as us-east-1
, using
the following policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
}
}
}
]
}
In the next section (Configuring Resolvers), we'll add our resolver business logic and attach it to the fields in our schema to process the data in our data source.
For more information regarding role policy configuration, see Modifying a role in the IAM User Guide.
For more information regarding cross-account access of AWS Lambda resolvers for AWS AppSync, see Building cross-account
AWS Lambda resolvers for AWS AppSync