Appsync | Unified Repo

Use @graphql-codegen/cli to generate TypeScript types for your Lambda resolvers:

// packages/data-sources/src/types/graphql.ts generated from schema.graphql
export type QueryGetPostArgs =  id: string ;
export type Post =  id: string; title: string; content: string ;
// Now your Lambda is fully typed
import type  QueryGetPostArgs, Post  from './types/graphql';
export const handler = async (event: AppSyncResolverEvent<QueryGetPostArgs>): Promise<Post> => 
const  id  = event.arguments;
// Your logic here...
;

No more manual type updates when the schema changes. Run yarn generate and the unified repo syncs everything.

✅ Single source of truth – All AppSync interactions go through one repository
✅ Type safety – Full TypeScript generics for inputs/outputs
✅ Reusability – Create repositories for different models with minimal code
✅ Real-time ready – Subscriptions built-in
✅ Testable – Easy to mock appSyncClient for unit tests
✅ Consistent error handling – Centralized error management

This pattern scales well from small projects to large enterprise applications using AWS AppSync. appsync unified repo

Before diving into the how, let's address the why. AppSync has unique characteristics that make a unified repository exceptionally valuable.

The AppSync Unified Repository is not a silver bullet. It is best suited for:

Avoid it if:

However, for the vast majority of teams, the Unified Repository transforms AWS AppSync from a configuration headache into a developer experience dream. It forces schema coherence, enables local testing of resolvers with mocks, and makes "deploy the entire API" a trivial, one-command operation.

Do not hardcode environment names. Use CDK contexts:

const stage = this.node.tryGetContext('stage') || 'dev';
const userPoolId = stage === 'prod' ? 'xxx' : 'yyy';