Advanced Features of Appsync and GraphQL within AWS Amplify Framework скачать в хорошем качестве

Advanced Features of Appsync and GraphQL within AWS Amplify Framework

This recording of a meeting shows an example usage of 4 advanced/lesser-known features and capabilities of Appsync inside of AWS Amplify. Many of these features require Amplify GraphQL Transformer 2.0; Where this major version upgrade is required to use the feature, the dependency is explicitly called out. The 4 features are: 1. Override Pipeline Resolvers With the release of GraphQL API Transformer 2.0, the generated resolvers are pipeline resolvers, which you can read about here: https://docs.aws.amazon.com/appsync/latest.... With transformer 1.0, Appsync will not by default generate pipeline resolvers, so these overrides will not be possible. Note that you can see the version of the GraphQL transformer that you are using inside the cli.json file in your amplify directory. In the example, I include an additional few fields in the default record created by the Create{type} resolver autogenerated by the GraphQL compiler. More info here: https://docs.amplify.aws/cli/graphql/custo... 2. Strongly-Typed function inputs and outputs This "feature" is available in both versions of the graphql transformer but is not necessarily obvious; In the documentation: https://docs.amplify.aws/cli/graphql/custo... all functions have String inputs and String outputs, but it does not have to be that way. Basically, by defining the type of the inputs and outputs for lambda functions, you will give your FE developers improved ability to understand the function interface and most effectively utilize the function. It also reduces the amount of code you need to write inside your lambda to decrypt the input payload and confirm that the correct fields have been received. More info here: https://docs.amplify.aws/cli-legacy/graphq... . You can see in this example how they return a complex Post type from the lambda function or User type. You can do the same with inputs and show clearly which are required vs non required inputs with “!”: Just make sure that you are NOT resolving your function inputs + outputs with objects that are dumped into json Strings; This is a complete misuse of the power of GraphQL and neglects the capacity of AWS Appsync to do your type-checking and schema validation for you. 3. Split Schema Definitions Conventionally, we have defined our schemas inside of the same schema.graphql file in the amplify/backend/api folder in each amplify repo. However, amplify supports splitting the schema definition into many files, which can help to reduce merge conflicts and instances of amplify push overwriting changes from other developers in DEV environment. It also helps to clarify where/how each schema element is used and makes it easier to deprecate unused schema definitions. More info here: https://docs.amplify.aws/cli-legacy/graphq... 4. Custom Resolvers: These allow you to define and build completely custom resolvers for arbitrary queries or mutations on GraphQL. For reference, the way GraphQL works is: GraphQL API Endpoint to/from Resolver to/from Data Source. With custom resolvers, you can write your own logic in Velocity/VTL language. In this demo, we will show how we created resolver that transforms data defined inside the endpoint into a query or change to the Data Source. More info here: https://docs.amplify.aws/cli/graphql/custo... You can, of course, neglect VTL and directly connect your Appsync API to a lambda function via the `@function` directive in Amplify. However, for simple GraphQL operations on a single data source, a function may be overkill. Additionally, note that in November 2022 the Amplify team released the ability to create these custom resolvers using CDK, so you no longer need to use VTL.