Appsync Unified Repo Here
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:
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.
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. appsync unified repo
Example resolver ( getPost.ts ):
In packages/web/package.json :
{ "scripts": { "codegen": "graphql-codegen --config codegen.yml", "build": "npm run codegen && vite build" } } The codegen.yml points to the local schema file:
// Attach a resolver using the new JS runtime postDS.createResolver('getPostResolver', { typeName: 'Query', fieldName: 'getPost', code: appsync.Code.fromAsset('graphql/resolvers/getPost.js'), runtime: appsync.FunctionRuntime.JS_1_0_0, }); In a unified repo, you can write resolvers in TypeScript and transpile them to the AppSync JS runtime. Store resolvers as .ts files and build them to resolvers/ during deployment. schema:
Enter the (monorepo). By managing your AWS AppSync configuration—schema, resolvers (VTL or JavaScript), datasources, and even client code—in a single repository, you can enforce consistency, improve developer experience, and streamline CI/CD.
