Let’s dive deep into AWS AppSync, a fully managed GraphQL service, which does a lot for a little.

In this article, we are going to learn how to leverage a fully managed GraphQL solution by AWS. That service is called, AWS AppSync. In the following sections, we will go through what is AppSync, what are the benefits, how AppSync connects to other AWS services, and finally breakdown an architecture diagram which uses GraphQL for a real-time chat application!

What is AppSync?

AppSync, as stated above, is a fully managed GraphQL solution which adds additional functionality on top of GraphQL. There is a lot that AppSync gives us, but the biggest advantage is AppSync streamlines the connection to your backend resources. These connections are called data sources and resolvers.

Data sources and resolvers are how AWS AppSync translates GraphQL requests and fetches information from your AWS resources. AWS AppSync has support for automatic provisioning and connections with certain data source types. You can use a GraphQL API with your existing AWS resources or build data sources and resolvers. — AWS AppSync Resolvers Tutorial

AppSync now also supports the following resolvers

These resolvers hook directly up to your AppSync API and streamline the connections to your backend resources. It’s a beautiful thing.

• DynamoDB Resolvers — hook directly into the DynamoDB service
• Elasticsearch Resolvers — hook directly into the Elasticsearch service
• Aurora Serverless Resolvers— execute SQL statements against MySQL or PostgreSQL databases 💥
• HTTP endpoints —connect to existing REST APIs 👍
• Pipeline Resolvers — link resolvers together to execute sequentially 🔥
• Delta Sync Resolvers — more efficient caching

What are the benefits?

AppSync cuts down implementation time by reducing the amount of code you need to write. I’ve had a ringing in my ear since I started development which was, “the best code is the code you don’t write”. Since then Serverless Guru has adopted this as a mantra to always keep in mind when developing. By not writing code to handle simple database queries and mutations and leveraging built-in resolvers, we reduce the time spent planning, debugging, developing, and the cherry on top we spend less time in meetings.

The best code is the code you don’t write — Serverless Guru Mantra

AppSync also accelerates development because when you abstract away the part of your backend which simply parses the request then hits your database and responds. Everyone is freed up to spend more energy towards the unique functionality that the application requires. Making the entire team move faster and be more agile.

AppSync will save you money upfront on infrastructure cost. AppSync eliminates the need to have a server or even a cloud function running to handle simple request and responses from the database. Not only that, if we leverage built-in resolvers by AppSync, we are further led towards fully managed solutions and spend less time making the machines work.

AppSync works into existing AWS infrastructure automation. Meaning you can take advantage of the service without jumping into the AWS console and manually configuring everything from scratch. You can create AppSync APIs using Cloudformation and most other third-party automation solutions.

At Serverless Guru, we use the Serverless Framework to build our applications for clients and to build any AppSync APIs we use a plugin called Serverless AppSync Plugin.

Behind AppSync is GraphQL and GraphQL is powerful

GraphQL gives us subscriptions for real-time communication, self-documenting APIs, built-in request error handling, and a visual UI (GraphiQL) of the API.

GraphQL also gives us well-defined schemas. These schemas make it easy for other developers to understand all the fields that could be in the request without diving into any backend code.

As a frontend developer working with a GraphQL API, you can define the GraphQL requests however you want. Meaning that the frontend can say, “give me every user record, but only their phone numbers” and “give me every user record and all fields”. These two statements are telling GraphQL to limit the response fields and we didn’t have to write code in the backend to do that 🔥.

Where a REST API can fall down

A typical REST API would need logic which accepts the client request, formats the request for the database, hits the database, then formats the database response, and finally responds back to the client.

In that traditional flow, we can immediately see numerous places that would require research, planning, communication, development, debugging, and testing. Every one of these areas can dramatically increase the delivery date.

Proactively choosing solutions which limit your overall footprint is a great way to point the gun away from your foot and save on trips to the hospital.

At Serverless Guru, one of the primary consulting areas we offer to clients is working into their existing applications and working within an existing team. What we’ve seen is a lot of variance around how to build an API, how to extend an API, where things get out of control, and how to limit the chaos.

We’ve also had the ability to analyze the different implementation approaches and we’ve found that a large amount of API development is done to handle simple CRUD (Create, Read, Update, Delete) operations. Something that AppSync streamlines.

Where AppSync falls down

AppSync has a lot of pros and I’ve mentioned those in a fair amount of detail above. However, let’s get into the ways that it can be more difficult than a typical REST API.

Learn GraphQL — When you move to GraphQL from a background with building REST APIs, you’re going to need to learn the inner workings of GraphQL. This can be quite the lift.

Learn AppSync — Once you learn GraphQL, you will then need to learn where GraphQL stops and AppSync begins. That can take a while to understand. Like anything else, start small and scale up.

Learn Supporting Services — Once you’ve got a grip on GraphQL and are doing basic things with AppSync then you will want to crank that up and learn services such as Cognito, DynamoDB, Aurora Serverless, and Lambda. These services are fully managed by AWS and handle authentication, NoSQL or SQL, and compute. Allowing you to supercharge your application.

Less control — Once you’re cooking with fire and really starting to make progress, you may get caught not understanding VTL (Velocity Templating Language) which is how AppSync communicates with resolvers. Then when things break, you may have trouble finding the root cause. Due to the handoffs between a client request to GraphQL and AppSync data sources and resolvers.

As a cloud-native consulting company

Serverless Guru, provides application development consulting to clients who are trying to break into the cloud-native or serverless space. As well as clients that are trying to optimize their existing infrastructure already on the cloud.

When it comes to cloud-native consulting, it’s always about providing as much value as possible to the client while at the same time reducing the overhead, time, and cost in the solution. We do that through leveraging fully managed solutions like AWS AppSync because of all the reasons mentioned above.

How does AppSync connect to other AWS services

As we talked about above, AppSync uses templates to map the requests and responses from your GraphQL schema to supporting AWS services. This is done through configuring data sources and resolvers.

For our purposes, we are going to be using AWS DynamoDB a fully managed NoSQL database as our resolver and our data source. The following things will happen when our application needs to do CRUD (Create, Read, Update, Delete) operations:

• Frontend makes an HTTP request to our AppSync API
• AppSync uses our GraphQL schema to validate the request
• AppSync uses our request mapping template to map the request to our data source
• AppSync uses our response mapping template to map the response from our data source
• Frontend receives an HTTP response from our AppSync API

Alright, let’s get into the mapping templates which replace the server or cloud functions which would typically handle this interaction.

Request Mapping Template

Below is a simple request mapping template which will expect an id in the request and then will query DynamoDB using the operation GetItem.

  
{
  "version": "2017-02-28",
  "operation": "GetItem",
  "key": {
    "id": $util.dynamodb.toDynamoDBJson($ctx.args.id)
  }
}
  

Response Mapping Template

Below is a simple response mapping template which just responds with the result of the query and it even turns the database response into JSON. All in a single line.

  
$util.toJson($ctx.result)
  

To reiterate, that is all we need. We don’t need anything else. No server or cloud function. We don’t have any backend code to make this work. We just tell AWS AppSync if someone requests our GraphQL query function use the associated request mapping template and response mapping template! Boom. We have just queried the database with no server-side logic.

If you’re still with me, let’s jump into a diagram created by AWS, called Building a serverless real-time chat application.

Breaking down the ChatQL architecture

This diagram shows a Serverless way to implement a real-time application. The application does not need to be a chat application. We can reuse this knowledge for any backends, be it web, mobile, desktop, etc.

In the diagram above we labeled from A-I, where each letter is a different component worth discussing.

A — The user logs into our application and makes a request to our AppSync API.

B — Cognito is a fully managed authentication service which allows users of our application to log in and receive a JWT token. The JWT token is then passed to our AppSync API. If the JWT is missing or invalid the request fails.

C — GraphQL Queries and Mutations are the terms that GraphQL uses to describe CRUD operations. A GET request would be a query and a POST/PUT/DELETE would be a mutation.

D — AppSync is the brain which receives the request, validates the request, passes the request to a resolver, and handles the response back to the client

E — AppSyn Data Sources are the resources (e.g. DynamoDB) attached to a specific resolver.

F — DynamoDB is our NoSQL database which hooks directly into AppSync and allows us to do CRUD operations without any server-side code

G — AppSync Resolvers allow us to connect a GraphQL query or mutation to a set of request and response mapping templates which in turn connect to an AppSync Data Source

H — GraphQL Schema defines our API queries and mutations. In the request, the GraphQL schema defines the fields which can be sent and the data types of those fields (e.g. string, object, number). In the response, the GraphQL schema defines the fields which can be returned, it can be scoped down to a few fields or all the fields. The frontend can then choose how many fields they need for that query.

I — GraphQL Subscriptions allow you to create real-time applications which are listening for updates and will automagically trigger if those conditions are met.

Serverless Guru, will typically build new web applications similar to the diagram shown above with a little variance based on the use-case and client requirements.

This has been Ryan Jones from Serverless Guru, thanks for reading and good luck stepping into the world of AppSync and GraphQL. 👋

‍