Taming the GraphQL Beast: Managing AWS AppSync in a Unified Repository
{ "scripts": { "codegen": "graphql-codegen --config codegen.yml", "build": "npm run codegen && vite build" } } The codegen.yml points to the local schema file:
Because everything lives in packages/api , any frontend change that expects a new field forces you to update the resolver in the same PR . The magic of the monorepo happens in package.json scripts. After every schema change, regenerate all clients automatically.
import { util } from '@aws-appsync/utils'; import { get } from 'aws-appsync-resolver-helpers'; // your own helpers export function request(ctx: any) { return { operation: 'GetItem', key: util.dynamodb.toMapValues({ id: ctx.args.id }), }; }
// packages/api/lib/appsync-stack.ts import * as appsync from 'aws-cdk-lib/aws-appsync'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; const api = new appsync.GraphqlApi(this, 'MyUnifiedApi', { name: 'UnifiedBlogApi', schema: appsync.Schema.fromAsset('graphql/schema.graphql'), // single source of truth });
schema: ../api/graphql/schema.graphql documents: src/**/*.graphql generates: src/generated/graphql.ts: plugins: - typescript - typescript-operations - typescript-react-apollo Now, when a developer runs npm run build in the web package, they always use the latest schema from the api package. No more out-of-sync copies. Your CI pipeline (GitHub Actions, GitLab CI) should enforce integration. Here is a typical workflow:
// DynamoDB datasource const postTable = new dynamodb.Table(...); const postDS = api.addDynamoDbDataSource('PostDS', postTable);
Start with a simple two-package structure ( api + one client), then expand. The tooling (CDK, GraphQL Codegen, npm workspaces) is mature enough for production today.
Unified Repo — Appsync
Taming the GraphQL Beast: Managing AWS AppSync in a Unified Repository
{ "scripts": { "codegen": "graphql-codegen --config codegen.yml", "build": "npm run codegen && vite build" } } The codegen.yml points to the local schema file:
Because everything lives in packages/api , any frontend change that expects a new field forces you to update the resolver in the same PR . The magic of the monorepo happens in package.json scripts. After every schema change, regenerate all clients automatically. appsync unified repo
import { util } from '@aws-appsync/utils'; import { get } from 'aws-appsync-resolver-helpers'; // your own helpers export function request(ctx: any) { return { operation: 'GetItem', key: util.dynamodb.toMapValues({ id: ctx.args.id }), }; }
// packages/api/lib/appsync-stack.ts import * as appsync from 'aws-cdk-lib/aws-appsync'; import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'; const api = new appsync.GraphqlApi(this, 'MyUnifiedApi', { name: 'UnifiedBlogApi', schema: appsync.Schema.fromAsset('graphql/schema.graphql'), // single source of truth }); Taming the GraphQL Beast: Managing AWS AppSync in
schema: ../api/graphql/schema.graphql documents: src/**/*.graphql generates: src/generated/graphql.ts: plugins: - typescript - typescript-operations - typescript-react-apollo Now, when a developer runs npm run build in the web package, they always use the latest schema from the api package. No more out-of-sync copies. Your CI pipeline (GitHub Actions, GitLab CI) should enforce integration. Here is a typical workflow:
// DynamoDB datasource const postTable = new dynamodb.Table(...); const postDS = api.addDynamoDbDataSource('PostDS', postTable); import { util } from '@aws-appsync/utils'; import {
Start with a simple two-package structure ( api + one client), then expand. The tooling (CDK, GraphQL Codegen, npm workspaces) is mature enough for production today.