AWS AppSync GraphQL scalars and directives to support type completion and error checking in Webstorm IDEs

_aws.graphql

# These are here to help the IDE recognise AWS types.
#
# Place this file outside the 'schema' directory so are not pushed to AWS,
# but are still picked up by PhpStorm's GraphQL plugin to help
# validate schemas.
#
# https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html
#
scalar AWSDateTime
scalar AWSDate
scalar AWSTime
scalar AWSTimestamp
scalar AWSEmail
scalar AWSJSON
scalar AWSURL
scalar AWSPhone
scalar AWSIPAddress

#
# The below directives came from a GitHub issue here:
# https://github.com/apollographql/eslint-plugin-graphql/issues/263
#

"""This directive allows results to be deferred during execution"""
directive @defer on FIELD

"""
Tells the service this field/object has access authorized by an OIDC token.
"""
directive @aws_oidc on OBJECT | FIELD_DEFINITION

"""Directs the schema to enforce authorization on a field"""
directive @aws_auth(
    """List of cognito user pool groups which have access on this field"""
    cognito_groups: [String]
) on FIELD_DEFINITION

"""
Tells the service which subscriptions will be published to when this mutation is
called. This directive is deprecated use @aws_susbscribe directive instead.
"""
directive @aws_publish(
    """
    List of subscriptions which will be published to when this mutation is called.
    """
    subscriptions: [String]
) on FIELD_DEFINITION

"""
Tells the service this field/object has access authorized by a Cognito User Pools token.
"""
directive @aws_cognito_user_pools(
    """List of cognito user pool groups which have access on this field"""
    cognito_groups: [String]
) on OBJECT | FIELD_DEFINITION

"""Tells the service which mutation triggers this subscription."""
directive @aws_subscribe(
    """
    List of mutations which will trigger this subscription when they are called.
    """
    mutations: [String]
) on FIELD_DEFINITION

"""
Tells the service this field/object has access authorized by sigv4 signing.
"""
directive @aws_iam on OBJECT | FIELD_DEFINITION

"""
Tells the service this field/object has access authorized by an API key.
"""
directive @aws_api_key on OBJECT | FIELD_DEFINITION
directive @auth(rules: [AuthRule!]!) repeatable on OBJECT | FIELD_DEFINITION
input AuthRule {
    allow: AuthStrategy!
    provider: AuthProvider
    ownerField: String # defaults to "owner" when using owner auth
    identityClaim: String # defaults to "username" when using owner auth
    groupClaim: String # defaults to "cognito:groups" when using Group auth
    groups: [String]  # Required when using Static Group auth
    groupsField: String # defaults to "groups" when using Dynamic Group auth
    operations: [ModelOperation] # Required for finer control

    # The following arguments are deprecated. It is encouraged to use the 'operations' argument.
    queries: [ModelQuery]
    mutations: [ModelMutation]
}
enum AuthStrategy { owner groups private public }
enum AuthProvider { apiKey iam oidc userPools }
enum ModelOperation { create update delete read }

# The following objects are deprecated. It is encouraged to use ModelOperations.
enum ModelQuery { get list }
enum ModelMutation { create update delete }

directive @connection(keyName: String, fields: [String!]) repeatable  on FIELD_DEFINITION
directive @key(name: String!, fields: [String!]) repeatable on OBJECT | FIELD_DEFINITION
directive @model(
    queries: ModelQueryMap
    mutations: ModelMutationMap
    subscriptions: ModelSubscriptionMap
    timestamps: TimestampConfiguration
) repeatable on OBJECT
input ModelMutationMap {
    create: String
    update: String
    delete: String
}
input ModelQueryMap {
    get: String
    list: String
}
input ModelSubscriptionMap {
    onCreate: [String]
    onUpdate: [String]
    onDelete: [String]
    level: ModelSubscriptionLevel
}
enum ModelSubscriptionLevel {
    off
    public
    on
}
input TimestampConfiguration {
    createdAt: String
    updatedAt: String
}

If I'm using amplify CLI, where is best to place this file? I ask, because I don't have a schema directory. I have an amplify directory at my project root.

Okay, I think I figured out an acceptable solution. I just realized that with Amplify, your API can be set up as a schema.graphql file or as a schema directory with .graphql files under it. So the comment at the top of the file to store this "outside of your schema directory" makes more sense now. So I chose to put mine at <project>/amplify/backend/api/_aws.graphql as it seems that additional APIs may be created with Amplify and stored under amplify/backend/api/ and just having the file at this level tells me it is relevant to all APIs under this folder and is enough for Webstorm to pick it up and squash all the complaints present in the Amplify getting started tutorial.

Thanks @davidimoore!