Single Table DynamoDB with GraphQL

tldr; https://github.com/ChristopherBiscardi/dynamo-netlify-graphql-single-table-example

Alex Debrie wrote a fantastic piece on single and multi table data modeling with DynamoDB: The What, Why, and When of Single-Table Design with DynamoDB. I highly suggest you go read it. Great. Now that you've read it, in the post he makes a claim about DynamoDB single table design and its application to GraphQL.

The second place where you may want to avoid single-table design with DynamoDB is in GraphQL applications.

He supports this claim by claiming that resolvers are sequential, and therefore a query with multiple sub-selections would require multiple serial database requests.

The problem is that resolvers are essentially independent from each other. In the example above, the root resolver would execute first to find the User with ID 112233. This would involve a query to the database. Then, once that data is available, it would be passed to the Order resolver in order to fetch the relevant Orders for this User. This would make subsequent requests to the database to resolve those entities.

A simple example

For this example I'll use Netlify functions and apollo-server-lambda, a JS implementation of a GraphQL server. The query in question fetches a user of id "112233" and gets the firstName, lastName, addresses, and orders.

query {
  user( id: "112233" ){ 
    firstName 
    lastName 
    addresses
    orders { 
      orderDate
      amount
      status
    }
  }
}

which requires a schema that looks something like this:

type Query {
  user: User
}
type User {
  firstName: String
  lastName: String
  addresses: String
  orders: Order
}
type Order {
  orderDate: String
  amount: String
  status: String
}

DynamoDB

So we'll say that we have Users, Addresses, and Orders. Our primary data type for access in this scenario is the User. Our user has some metadata of it's own, a number of addresses, and a number of orders. We can represent our data in the following single table design.

In rest form, we could get all of the data with the following DynamoDB query.

const params = {
  TableName: "dynamo-single-table-graphql",
  KeyConditionExpression: "pk = :user",
  ExpressionAttributeValues: {
    ":user": `user#112233`
  }
};
const { Items } = await docClient.query(params).promise();

It turns out that because we can't perform OR in a KeyConditionExpression, that we can't limit the data we're querying for. We can use FilterExpressions, but that's probably not what we want here.

Does this refute Alex's point. Well, not nearly as strongly as I wanted to. It does do away with the notion that resolvers need to fire sequentially, but we still need to fetch all of the data almost indiscriminately from the database anyway. So we get some UI side wins for using GraphQL (1 request to the backend) and we get some potential wins from API to DB (in this case one request again) but we don't get full control and have to spend all of the RCUs we would normally have spent anyway.