amplify and appsync

AppSync

AppSync is technically separate from Amplify, but it seems like it's built in such a way so as to basically require you using amplify's toolset to work with it sustainably.

Example Schema

schema {
  query: Query
  mutation: Mutation
}

type Query {
  allTodo: [Todo]
}

type Mutation {
  addTodo(
    id: ID!
    name: String
    description: String
    priority: Int
    status: TodoStatus
  ): Todo
}

type Todo {
  id: ID!
  name: String
  description: String
  priority: Int
  status: TodoStatus
}

enum TodoStatus {
  done
  pending
}

Schema Creation

Notice that the id field is automatically generated. AWS AppSync does this if your type has a Primary Key field on a table of id: ID!. Otherwise, AWS AppSync require the Primary Key field to be passed

AWS AppSync creates filters on GraphQL scalar types (that is, ID, String, Int, Float, Boolean) for list operations. ... For example, only String supports BEGINS_WITH while Boolean supports EQ, NE, etc.

VTL

Velocity Template Language is the thing that goes straight from API Gateway into DynamoDB (or another storage). It is a replacement for lambdas that don't incur cold starts and such.

# Generating an id on the server When creating a item that needs a unique identifier, you may not want to create an id manually at the client level, & instead depend on the server to do so. You can do so easily using $util.autoId(). This type of ID is actually built in when you create an API using the autamtic API builder, but sometimes you may need it in other circumstances (like when you manually need to create or update a resolver.).] - top 9 aws appsync features you didn't know about

{
  "version": "2017-02-28",
  "operation": "PutItem",
  "key": {
    "id": $util.dynamodb.toDynamoDBJson($util.autoId()),
  },
  "attributeValues": $util.dynamodb.toMapValuesJson($ctx.args.input)
}

Amplify

A bucket of extra tooling that works over the top of a bunch of services. There are some features with seem exclusive to amplify, such as offline support with datastore.

Amplify is chock-full-o-codegen. Everything you do seems to revolve around codegen'ing a bunch of stuff.

DataStore

DataStore can connect to an AppSync backend and automatically sync all locally saved data using GraphQL as a data protocol.

Schema updates

This will evaluate the changes and create a versioned hash if any changes are detected which impact the underlying on-device storage structure. For example, types being added/deleted or fields becoming required/optional. DataStore evaluates this version on startup and if there are changes the local items on device will be removed and a full sync from AppSync will take place if you are syncing with the cloud.

Local migrations on device are not supported. If you are syncing with the cloud the structure and items of that data in your DynamoDB table will not be touched as part of this process.

Does that mean local data just gets deleted if the API changes?

On Subscriptions

In these cases it’s important that the selection set of your GraphQL mutation includes the fields _lastChangedAt, _version, and _deleted so that the DataStore clients can react to these updates. You will also need to send the current object version in the mutation input argument as _version so that the service can act accordingly. If you do not send this information the clients will still eventually catch up during the global sync process, but you will not see realtime updates to the client DataStore repositories. An example mutation:

mutation UpdatePost {
  updatePost(input: {
    id: "12345"
    title: "updated title 19:40"
    status: ACTIVE
    rating: 5
    _version: 7
  }) {
    id
    title
    status
    rating
    _lastChangedAt
    _version
    _deleted
  }
}