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.
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.
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
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 can connect to an AppSync backend and automatically sync all locally saved data using GraphQL as a data protocol.
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?
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: