Why doesn't Appsync use DAX for caching rather than ElasticCache for Redis?

AppSync is a managed GraphQL service that handles the API delivery and scaling pieces of your architecture. GraphQL/AppSync is not limited to only working with DynamoDB, however. It supports a wide variety of data sources including DynamoDB, generic NoSQL databases, SQL databases, HTTP endpoints and micro-services.

As a result, AppSync needs to leverage a caching mechanism that is not specific to a particular datastore like DynamoDB/DAX. If you have a pipeline resolver, as an example, that is assembling data from DynamoDB, RDS, and API Gateway REST endpoints, the AppSync caching layer (in ElastiCache) will retain that data for you at either the API or resolver levels. As the previous poster noted, however, there is nothing preventing you from accessing your DynamoDB resources via DAX. You retain the control in terms of how you define your resolvers as to how it interacts with DynamoDB.

Hello,

AWS AppSync’s server-side data caching capabilities backed by Amazon ElastiCache for Redis, makes data available in a high speed, in-memory cache, improving performance and decreasing latency.

If you want to connect AppSync with DynamoDB, you can use Unit Resolvers which provide a direct resolver connection to DynamoDB. Unit resolvers run against the Database, thereby providing a singular response and request mapping template using Apache Velocity Template Language (VTL). A request will be taken as input, and then outputs a JSON document with instructions for the resolver.

To learn more about Unit Resolvers, work through the how to configure resolvers developer guide.

Further more:

Caching within AppSync works at two levels:

Caching across the full API:

This means, If the data is not in the cache, it is retrieved from the data source and populates the cache until the time to live (TTL) expiration. All subsequent requests to the API are returned from the cache. This means that data sources aren’t contacted directly unless the TTL expires.

Caching per resolver level (including pipeline resolvers):

With this setting, each resolver must be explicitly opted in for it to cache responses.

Note: This is important as the other GraphQL endpoints don’t require caching in AppSync and with this situation, you can explicitly cache at the database level i.e. DynamoDB DAX.

This reduces the need to directly access data sources, whether that be Lambda, DynamoDB, Serverless Aurora, HTTP or more.

For certain endpoints you may look to utilise AppSync caching. The AppSync API resolves to DynamoDB through Lambda for its data, and you'd use DAX as a cache sitting in front of the database. You can utilise DAX to cache at the database level here.

I hope this helps.