Yesterday at reInvent, Amazon launched AppSync, a new GraphQL service featuring real-time updates and built-in offline support. Managed in the AWS console, AppSync’s GraphQL layer aggregates data from other AWS products such as ElasticSearch and DynamoDB. In your application, you query your GraphQL API with the AppSync Client, available for web and native.
The AppSync announcement got a lot of love from the developer community, and it’s easy to see why people are excited about GraphQL! Architecting your application with GraphQL enables you to build complex features quickly by simply describing your data requirements and letting your GraphQL layer take care of the rest. Companies like the New York Times, Coursera, and Express have led the way by powering their most important applications with GraphQL.
Naturally, we were curious to learn more about AppSync. Once we dug into the open-source code, we were excited to see that the AppSync Client implementations are based on the same MIT-licensed Apollo technology you know and love: Apollo Client 2.0, Apollo iOS, and Apollo Codegen! Read on to learn how different components of these Apollo projects power some of the coolest features of the AppSync platform.
Last month, we officially released Apollo Client 2.0 at GraphQL Summit 2017. In addition to making it smaller and faster, one of our main goals was to also make it much more modular. You now have the ability to plug in your own cache and tailor your network stack to your application’s requirements with Apollo Link.
It turns out that Apollo Client 2.0’s modular architecture was a huge win for developers looking to customize their GraphQL client, because that’s exactly how the AWS team was able to build AppSync Client!
In only a few weeks, the AWS team was able to make complex features like offline support and authentication a reality by extending the Apollo
InMemoryCache and using Apollo Link to customize their network interface. We think this is a testament to the extensibility of Apollo Client and hope their example inspires more teams to experiment with personalizing their GraphQL client. Let’s dive into how AWS accomplished this.
To achieve offline support, the AWS team created a custom Apollo Link that takes a Redux store augmented by for persistence. This link also queues up any pending mutations and calls to refetch queries when the device is offline and stores them in a Redux subtree to be executed when the device goes back online. Since the AppSync Client is based on Apollo Client, you still get the benefit of optimistic UI responses even if the device is offline when the mutation is fired.
We’re also working on improving the offline experience to create easy persistence that isn’t dependent on Redux and advanced features such as applying a timeout to the offline mutation queue to avoid potential conflicts. If you’d like to learn more about these initiatives, come join the party on the
apollo-cache-asyncstorage repo! 🎉 We’d love to hear your input and welcome any contributions.
One AppSync feature that generated a lot of buzz is its emphasis on real-time data. Under the hood, AppSync’s real-time feature is powered by GraphQL subscriptions. While Apollo bases its subscriptions on WebSockets via , subscriptions in GraphQL are actually flexible enough for you to base them on another messaging technology. Instead of WebSockets, AppSync’s subscriptions use MQTT as the transport layer.
The AWS team even wrote their own Apollo Link to execute subscriptions over MQTT, which we think is a really cool use case. If you’d like to integrate real-time features into your application in only a few lines of code with Apollo Link, please check out our example which serves queries & mutations over HTTP and subscriptions over WebSockets. We’d also like to hear from you on the repo if you have any suggestions on how to improve our transport layer.
To generate Swift types from AppSync’s GraphQL layer, AWS uses a customized version of Apollo Codegen. Apollo Codegen is a build tool that uses your GraphQL schema and queries to output types for a variety of different language targets: Flow, TypeScript, Java, Scala, and Swift.
We’re constantly working with the community to continuously improve the language targets; for example, Lewis Chung from Coursera published a revision to the Flow & TypeScript targets just this week! If you’re interested in generating static types from GraphQL and would like to strengthen the generated code or support additional targets like Reason, please reach out! We’d love to welcome you on board.
This content was originally published here.