Closed nikgraf closed 4 years ago
sounds good. Yes for mapping:
Each field in the schema can have resolver attached to it. In appsync resolver = request mapping template + response mapping template. Mapping templates in appsync are written in VTL, similar to use of mapping templates in other places in aws like api gateway. A resolver must have both request and response template.
Mapping templates must be attached once schema is created. So the flow is:
serverless.yml proposal
plugins:
- serverless-appsync-plugin
custom:
appsync:
name: # defaults to api
authenticationType: API_KEY | AWS_IAM | AMAZON_COGNITO_USER_POOLS # required
region: # defaults to provider region
mappingTemplates:
schema: # defaults schema.graphql
serviceRole: # required
dataSources:
name:
type: AWS_LAMBDA | AMAZON_DYNAMODB | AMAZON_ELASTICSEARCH
config:
tableName: 'Users' # required
So to confirm, this plugin handles custom AppSync config for:
and leaves Resource creation (DynamoDB, ElasticSearch, Lambda) to the serverless.yml config, does that sound right?
correct. appsync currently allows resource creation only via UI and not via SDK's https://github.com/awslabs/aws-mobile-appsync-sdk-js/issues/7
It looks like the plugin always creates an endpoint currently. Are there plans to include updating an existing one?
@ajagnanan that's correct. We do plan to add it in future but if you want, we can work together to include this feature. Is it something you would be interested in contributing?
oh man, if you could set it up the way you think it should work I'll be able to assist
lets think about it, can you please send me an email - sid88in@gmail.com and I can start a thread. thanks
On ‘serverless deploy’ it creates or updates the appsync schema. I suggest by default it uses the file ‘schema.graphql’ located in the root of the project.
Optionally the location of the schema file can be changed with a parameter nested in the custom section in serverless.yml. A possible name could be ‘graphqlSchema’
The API calls should happen after the new resources and functions are deployed so they can be referenced and it doesn’t happen that a schema goes live that doesn’t have the necessary resources up & running.
On ‘serverless remove’ the appsync schema is removed as well. Here it happens before the cloudformation stack is removed.
Note: I don’t know to much about the mappings yet. Will read up on them and we can extend/update/correct this initial draft.