Great question—let’s break this down step by step since I’ve dealt with similar patterns in AppSync + DynamoDB setups.

First: Is Denormalization a Valid Approach? #

Absolutely. Denormalization is encouraged in DynamoDB for optimizing read performance, which fits your use case perfectly:

• Pros:
  • Users can fetch their registered events directly from the User table without needing to join or query a separate table.
  • Events can pull participant details instantly from their own users array instead of cross-referencing a User table every time.
  • Avoids the overhead of secondary indexes or batch queries that come with a normalized "join" table.
• Cons to Consider:
  • If an event’s title changes, you’ll need to update that title in every User record that includes it in their events array. Similarly, if a user updates their name, you’ll have to propagate that change to all Event records they’re part of.
  • This creates eventual consistency risks unless you add a sync mechanism (like DynamoDB Streams + Lambda to propagate updates across tables).

When to Use a Join Table Instead? #

Opt for a third UserEvent join table only if:

• Event/user metadata changes frequently (making denormalization sync overhead too high).
• You need to track additional relationship-specific data (like registration timestamp, ticket type, etc.).
• Your app scales to thousands of events per user or thousands of users per event—denormalized arrays can get unwieldy with extremely large datasets.

Second: Updating Two Tables in a Single Mutation #

You don’t have to use Pipeline Resolvers, but they’re the most native, low-overhead option. Here are your two main paths:

Option 1: Pipeline Resolvers (AppSync Native) #

Pipeline Resolvers let you chain multiple resolver functions into a single mutation, each handling one table operation. Here’s how to set it up:

1. Define your mutation:

   type Mutation {
     signUpForEvent(input: SignUpInput!): SignUpResult
   }
   
   input SignUpInput {
     userID: ID!
     userName: String!
     eventID: ID!
     eventTitle: String!
   }
   
   type SignUpResult {
     user: User
     event: Event
   }
   

2. Create two resolver functions:
   • Function 1: Update User Table
     Request mapping template to add the event to the user’s events array:

     {
       "version": "2018-05-29",
       "operation": "UpdateItem",
       "key": { "userID": { "S": "${context.arguments.input.userID}" } },
       "update": {
         "expression": "SET events = list_append(if_not_exists(events, :emptyList), :event)",
         "expressionValues": {
           ":emptyList": { "L": [] },
           ":event": { "L": [{"M": {
             "eventID": {"S": "${context.arguments.input.eventID}"},
             "title": {"S": "${context.arguments.input.eventTitle}"}
           }}]}
         }
       },
       "condition": { "expression": "attribute_exists(userID)" } // Ensure user exists
     }
     

   • Function 2: Update Event Table
     Similar template to add the user to the event’s users array:

     {
       "version": "2018-05-29",
       "operation": "UpdateItem",
       "key": { "eventID": { "S": "${context.arguments.input.eventID}" } },
       "update": {
         "expression": "SET users = list_append(if_not_exists(users, :emptyList), :user)",
         "expressionValues": {
           ":emptyList": { "L": [] },
           ":user": { "L": [{"M": {
             "userID": {"S": "${context.arguments.input.userID}"},
             "name": {"S": "${context.arguments.input.userName}"}
           }}]}
         }
       },
       "condition": { "expression": "attribute_exists(eventID)" } // Ensure event exists
     }
     

3. Assemble the Pipeline Resolver:
   Link the two functions in your mutation’s resolver. You can run them sequentially or in parallel (order doesn’t matter here). The response template can merge results from both functions to return the updated user and event.

Option 2: Lambda Resolver (More Flexible) #

If you need complex logic (like deduplicating existing event/user entries, validating permissions, or handling edge cases), a Lambda resolver is a better fit. Your Lambda function can:

• Take the mutation input.
• Use the DynamoDB SDK to perform UpdateItem (or PutItem) operations on both tables.
• Return the updated records to AppSync.

Critical Note: Atomicity #

If you need both table updates to succeed or fail together (no partial writes), use DynamoDB Transactions (TransactWriteItems). You can implement this either:

• In a single Pipeline Resolver function that calls the transaction API.
• In your Lambda function using the SDK’s transaction methods.

Transactions add a small overhead but guarantee atomicity for multi-table operations.

内容的提问来源于stack exchange，提问作者andy mccullough