Allow AppSync JavaScript resolvers to return arrays of operations for parallel execution (implicit fan-out)

[jay-herrera]

Proposal: Allow AppSync JavaScript resolvers to return arrays of operations for parallel execution (implicit fan-out)

Summary

This proposal suggests extending AppSync JavaScript resolvers so that if a request function returns an array of operation objects, AppSync executes those operations in parallel against the configured data source and returns an array of results to the response function.

This enables safe, bounded fan-out patterns natively within resolvers — eliminating the need for Lambda orchestration or multiple pipeline steps — while staying consistent with AppSync’s current execution and cost model.

---

Motivation

Currently, each AppSync resolver can only perform one operation per data source invocation.

If a developer needs to query or mutate multiple items (for example, GetItem for a list of IDs), they must either:

• Chain multiple pipeline functions (sequential, high latency)
• Use a Lambda resolver to implement the loop (adds cost and maintenance)
• Restructure logic around DynamoDB batch operations (less flexible, not available for all sources)

Allowing parallel execution of multiple operations within a single JS resolver would:

• Simplify dynamic fan-out and batch patterns
• Reduce resolver count and latency
• Maintain deterministic pricing and safe execution boundaries
• Enable more expressive, “data-graph-native” logic

---

Proposed Design

Example

export function request(ctx) {
  // Return an array of DynamoDB GetItem operations
  return ctx.arguments.ids.map(id => ({
    operation: 'GetItem',
    key: { id: { S: id } },
  }));
}

export function response(ctx) {
  // ctx.result is an array of results
  return ctx.result.map(item => $util.dynamodb.toMapValues(item.Item));
}

Behavior

• If the request function returns an array:
  • Each element is treated as a discrete operation request for the data source
  • AppSync executes all elements in parallel
  • The array of responses is passed to the response function as ctx.result
• If the request function returns a single object:
  • Current behavior remains unchanged

Behavior

• If the request function returns an array:

  • Each element is treated as a discrete operation request for the data source
  • AppSync executes all elements in parallel
  • The array of responses is passed to the response function as ctx.result

• If the request function returns a single object:

  • Current behavior remains unchanged

Error Handling

• Individual failures:
  • Can be represented as null in ctx.result
  • Or surfaced in a new ctx.resultErrors array
• Partial success semantics similar to BatchGetItem are acceptable

Implementation Constraints

• Max fan-out size: e.g., 25–100 parallel operations to preserve performance and safety
• Timeouts: all operations must complete within the existing resolver timeout budget
• Billing and metrics: each sub-operation counts as a single data-source call

Benefits

• Eliminates the need for Lambda resolvers in many batch-read/write cases
• Enables declarative fan-out and “per-item” patterns in pipelines
• Keeps resolvers simple and stateless, aligned with AppSync’s execution model
• Maintains backward compatibility
• Low implementation risk: behavior triggers only when Array.isArray(requestResult) is true

Alternatives Considered

• Multiple pipeline functions: sequential, verbose, slower
• DynamoDB BatchGetItem / TransactWriteItems: limited to DynamoDB, less flexible
• Lambda resolvers: higher latency, cost, and operational overhead

Example Use Cases

Multi-key lookups

export function request(ctx) {
  return ctx.arguments.memberIds.map(id => ({
    operation: 'GetItem',
    key: { userID: { S: id } },
  }));
}

Batch writes

export function request(ctx) {
  return ctx.arguments.items.map(item => ({
    operation: 'PutItem',
    key: { id: { S: item.id } },
    attributeValues: $util.dynamodb.toMapValues(item),
  }));
}

Dynamic fan-out pipelines

// Conceptual pipeline example:
// Before → FetchMembers → FetchProfiles (parallel fan-out) → FormatResponse

Closing

This proposal introduces a small, backwards-compatible enhancement that makes AppSync resolvers dramatically more expressive while maintaining deterministic and serverless characteristics.

It aligns with AppSync’s direction toward JavaScript-based resolvers and could serve as a foundation for future dynamic features such as conditional branching or sequential looping.