GraphQL API

The graphql starter composes a GraphqlStack around AtfAppSync. It drives an AppSync API from typed config — schema, data sources, and resolvers — and supports multiple APIs with distinct auth modes in one app. The example-graphql-full project is the full-breadth reference.

Shape of a GraphQL app

An AppSyncApiConfig describes one API: its schema, its auth modes (e.g. USER_POOL, API_KEY, IAM), its data sources (DynamoDB, HTTP, None), and its resolvers. example-graphql-full wires two APIs — a main API (User Pool + API key) and an admin API (IAM + User Pool) — against the same data layer.

Adding a resolver

axs add resolver is schema-aware: it reads your schema, offers the type/field targets, and scaffolds a VTL or JS UNIT resolver wired to a data source:

axs add resolver Query.listItems --type js --data-source ItemsTable

See the axs add resolver reference.

Feature layout — colocated resolvers

axs new --template graphql --layout feature organises resolver Lambdas by business domain under lambdas/features/<feature>/, and colocates each field’s resolver artifacts (.vtl / APPSYNC_JS .js) at lambdas/features/<feature>/resolvers/ — recorded as conventions.resolverLocation: "colocated" in axis.json. The SDL stays central at assets/schema.graphql: one schema is the cross-feature contract. axs add resolver then requires the owning --feature (prompted on a TTY) and emits into that feature’s tree. The example-graphql-full-feature project is the reference; the default module layout keeps every resolver artifact central under assets/resolvers/. See Layout: Module vs Feature.

Resolver kinds

• VTL — Apache Velocity request/response mapping templates, the classic AppSync path.
• JS — the APPSYNC_JS runtime resolver functions.

Pipeline resolvers (multiple functions per field) are on the roadmap; today axs add resolver scaffolds UNIT resolvers.

Where to go next

• AtfAppSync for the construct’s props, ID surface, and data-source model.
• SDK Generation — one typed operation per root field via @graphql-codegen.