.
├── graphql/ # Schema and Resolver definitions
│ ├── schema.graphql # Main GraphQL type definitions
│ ├── resolvers/ # VTL mapping templates (request/response)
│ └── functions/ # Lambda resolver source code
├── infrastructure/ # IaC configuration (CDK/Terraform/SAM)
├── scripts/ # Deployment and seed scripts
└── README.md
The schema.graphql file is the heart of your AppSync repo. Do not write it as one monolithic file. Use #import syntax (supported by AWS Amplify and CDK) to split it.
Example: types/user.graphql
type User @model
id: ID!
email: String! @aws_cognito_user_pools
profilePic: String
posts: [Post] @hasMany
Best Practice: Store enums, inputs, and interfaces in separate files. Use schema linting in your CI pipeline (graphql-schema-linter). appsync repo
In the modern cloud-native ecosystem, the term "AppSync Repo" can be ambiguous. For some, it refers to the AWS AppSync service itself—a managed GraphQL API layer. For developers and platform engineers, however, an AppSync Repo is the code repository (GitHub, GitLab, Bitbucket) containing the Infrastructure as Code (IaC), resolvers, schemas, and lambda functions that power that API. The schema
Whether you are building a real-time dashboard, a mobile backend for offline synchronization, or a federated gateway, how you structure your AppSync repository determines your team's velocity, security, and operational sanity. Best Practice: Store enums, inputs, and interfaces in
This article explores the anatomy of a perfect AppSync repo, best practices for CI/CD, and advanced patterns for managing GraphQL schemas at scale.