Let’s explore some common use cases for AWS AppSync, where AWS AppSync can help to build GraphQL APIs fast.
Simple Data-Centric GraphQL API
A typical use-case for AppSync is providing a data-centric API to an existing data source. The advantage of AppSync is the simplicity of building such a GraphQL API, especially when connecting to Amazon Elasticsearch, AWS Lambda or Amazon DynamoDB. Not having to set up any infrastructure allows for quick turnaround times. I show you, how this is done in the AWS App Sync Book.
Offline Access and Synchronization for Apps
AppSync clients may add local offline storage for the data delivered by the GraphQL API. This offline storage is a cache that works as follows: A copy of each query request and response is cached locally and for each mutation, the cache is updated with a write-through strategy, meaning the data is written both to the cache and to the GraphQL API.
Offline support allows us to create optimistic user interfaces, that provide a consistent user experience regardless of the current network availability. With an optimistic UI, data can be manipulated when the device is in an offline state.
Offline support is only a practical option if the client is able to synchronize offline data back to the server when it comes online again. Server-side and client-side conflict resolution in addition to the synchronization mechanism is needed to support this use case. Both are provided by AppSync.
I show you, how to set up offline support in the AWS App Sync Book.
Data Merging and Unification
Data merging is a common use case for GraphQL APIs, and AppSync supports this use case with its technology stack. In AppSync we do not need to decide on a single data source per API. We can connect as many data sources as we want to an AppSync API, all at the same time. Thus, an AppSync API is ideal for realizing the data merging use case, as I show you in the AWS App Sync Book.
The goals of data merging are:
- Connecting to multiple data sources, which can be databases, APIs, Lambda functions or Elasticsearch domains.
- Offering one common API, with one URL, on a common technology stack. Instead of having to navigate to various APIs on different URLs, which are each protected by their own security mechanism, the GraphQL API can offer all the data on one URL protected by a common security mechanism.
- Linking data from various data sources with each other, so we can navigate from the data provided by one data source to the data provided by another data source. In a database world, this would correspond to joining data from separate tables together. But in our case, we use GraphQLand its resolvers to implement the joining logic.
To realize data merging functionality efficiently with AppSync, there are a couple of constraints:
- The resolver for any single field should only be connected to one data source. This ensures that we can use the AppSync templates for writing resolvers.
- The data sources need to be AppSync compatible. Some data may be in an Amazon DynamoDB, other data may be in third-party software, accessible via API. To access the third-party APIs, we first need to create an AWS Lambda function as a proxy for each third-party API. Via these proxies, we can integrate the third party-APIs with AppSync.
I show you, how data merging use case can be realized in the AWS App Sync Book.
Also published on Medium.
