AWS AppSync: GraphQL an Alternative to REST 🌱

AWS AppSync: https://aws.amazon.com/appsync/

AWS AppSync

AppSync is a fully managed GraphQL service offered by Amazon Web Services and can be used to build scalable enterprise APIs. A typical AppSync solution consists of small resolvers that can be combined to access various data sources such as databases, HTTP APIs or AWS Lambda.

Why GraphQL and AppSync?

GraphQL has unique benefits when compared to REST, here are a few:

  • Consumers of the API control exactly the data they want to receive

For example, say we have a Music API that contains data for Artists, Songs, and Albums. Consumers requesting Artist information may only want the ArtistName and ArtistOrigin fields. By using GraphQL the consumer can request exactly those fields and other artist data will not cause wasted data transfer.

Query getBasicArtist{
getArtist(id: 1){
artistName,
artistOrigin
}
} //Result: { artistName: "Bob Dylan", artistOrigin: "UnitedStates"}

By leveraging this, your APIs can be used in a more flexible way; consumers can ask for varying sets of data without you having to make any updates to your backend API.

  • Consumers can ask for multiple data entities in a single HTTP Call

Consumers can also fetch information from other data entities in a single Query! Say we wish to fetch an Artists songs, we can perform:

Query getArtistSongs{
getArtist(id: 1){
artistName,
songs {
songName,
songReleaseDate
}
}
}//Result: { artistName: "Bob Dylan", songs: [{ songName: "Blowin in the wind", songReleaseDate: "08/13/1963"}...]

Traditionally with REST this would be two separate calls to GET api/artist and GET api/songs. This helps to reduce latency and complexity for the consumers of your API.

  • Validation and type checking out-the-box

With GraphQL you define a strongly typed Schema. This means by default you get type checking and high level validation at no extra cost.

For example, a strongly typed array of V4 UUIDs may be defined as:

Type MyCustomType{
uniqueIds: [ID!]!
} // represents an array of IDs. Since uniqueIds is also non-nullable, you can always expect an array (with zero or more items)

See more information on GraphQL Types here.

  • Code Sharing

With GraphQL schemas you can reuse strongly typed objects and properties across your API, implement fragments, union types and interfaces.

interface Song {
id: ID!,
name: string
duration: int
}
type SpotifySong implements Song {
id: ID!,
name: string,
duration: int,
spotifyUrl: string,
spotifyThumbnail: string
}
type DeezerSong implements Song {
id: ID!,
name: string,
duration: int,
deezerId: ID,
deezerTags: [string]
}

What about AppSync?

  • AppSync fits within a Serverless model nicely and can directly call internally to many of your AWS services! (SQS, SNS, DynamoDB, Lambda, RDS).
  • AppSync can also call out to external sources using HTTP Resolvers such as a legacy API or downstream service outside of AWS.
  • AppSync can protect against common API attacks with Rate limiting and AWS WAF configuration.
  • AppSync can be protected easily authorisation integrations with AWS Cognito or even custom Lambda authorisers.
  • AppSync Pipeline resolvers can introduce many custom Velocity template functions per request, where you can handle things like custom validation, data mutation and conditional logic all at no extra compute cost.

All sounds too good?

I’d like to give you some of the most common debates and concerns I’ve heard within teams when considering AppSync and GraphQL for their APIs.

Drawbacks of GraphQL:

  • Non-managed GraphQL solutions can be complicated to set up from scratch. Luckily, there are many frameworks or managed GraphQL solutions. Check out Apollo GraphQL here.
  • GraphQL may be a new technology for teams to adopt and learn. From experience, teams adopt the REST approach for its well known presence, familiarity in the industry and having existing knowledge with REST.
  • Complex Queries can reduce performance as data is fetched from multiple sources. You can enforce Rate limiting and Max-Depth limiting; Unfortunately at the time of writing, maxDepth limiting in AppSync can only be done inside a custom Velocity template, see here

Drawbacks of AppSync:

  • The main drawback of AppSync and something I would love to see in the future is private AppSync API’s to restrict the API to traffic within your VPC. API Gateway has a concept of private APIs, sadly you cannot yet do the same with AppSync.
  • Cloud/Vendor lock in. Whilst this is common with a service such as AppSync where business logic can be baked within Velocity templates at the infrastructure level, you should consider the long term strategy of your business case and what it means to migrate your AWS solutions to another provider. The likelihood of such event, in most cases, is relatively low.
  • Like all managed services, there may be a niche use case for high levels of custom configuration that may not be possible using a managed AWS service. As the service grows, more and more features are being added.

Summary

At the beginning, community led advice and documentation was sparse for both AppSync and GraphQL. I believe there is now a diverse and wide led GraphQL community.

AppSync has really matured over its lifetime and new integrations and features have been added that previously caused problems for startups to enterprises, such as AWS WAF support and Custom Authorisers.

I am not saying GraphQL is better than REST. You must carefully choose the right type of API for your application. You should always consider your specific use case including things like access and authorisation, types of consumers, etc. As mentioned above, if you need private APIs you only have the option for API gateway and REST.

I hope with the information above you can at least now consider GraphQL as an alternative to REST and see how it could be beneficial to your application.

This post has only touched upon some of the most common discussions when considering AppSync or GraphQL. There are plenty more resources that can dive deeper into AppSync GraphQL. For more information see the resources section below.

Getting in touch!

Happy building!… 🚀

Thank you for reading, Robert.

Reach me on linkedIn here: https://www.linkedin.com/in/robertbulmer/

--

--

--

Serverless Engineer/Architect UK —Helping others build resilient and maintainable software on AWS! 🚀 Support me @ https://www.buymeacoffee.com/rbulmer55 ☕️

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Golang is agnostic to particular programming paradigms. Here’s why.

programming and coding QA website

Plausible: Self-Hosted Analytics

Go2: Interface Default Methods?

My journey to become Microsoft Azure Solution Architect Expert

Kafka Producer & Consumer’ı Java ile kullanmak

Embedded Analytics — Integration

How to make a To Do app in Python Django

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Robert Bulmer

Robert Bulmer

Serverless Engineer/Architect UK —Helping others build resilient and maintainable software on AWS! 🚀 Support me @ https://www.buymeacoffee.com/rbulmer55 ☕️

More from Medium

Customized Rate Limiting with AWS API Gateway and Elasticache

AWS Amplify Pitfalls and Solutions

Commonly Used AWS Services

Seeding Huge Number of Records to Amazon RDS