ApiGatewayToDynamoDB: customize resource name on REST API

[fargito]

Hello, I would like to customize the generated resource name on my REST API when using ApiGatewayToDynamoDB.

Use Case

Currently, the resource name is generated from the DynamoDB partition key

aws-solutions-constructs/source/patterns/@aws-solutions-constructs/aws-apigateway-dynamodb/lib/index.ts

Line 152 in 0bc9043

const apiGatewayResource: api.Resource = this.apiGateway.root.addResource("{" + partitionKeyName + "}");

However, I am trying to implement a more complex use case where my integration will query on the sort key. It feel weird to have to write:

readRequestTemplate: `{ \
  "TableName": "${dynamodbTable.tableName}", \
  "KeyConditionExpression": "PK = :v2 AND SK = :v1", \
  "ExpressionAttributeValues": { \
    ":v1": { \
      "S": "$input.params('PK')" \
    }, \
    ":v2": { \
      "S": "MY_VALUE" \
    } \
  } \
}`,

I understand that this is the default use case, but it should be customizable IMO.

Proposed Solution

Add an optional resourceName string parameter on the construct and use it to define the resource name if it is passed. Otherwise, use the table's partition key like in the current implementation.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[biffgaut]

We understand the concept and can see the value - but when we read the snippet it looks reasonable to us. We will take a look at what an implementation involves - but could you provide an example of what the snippet would look like after the change you're proposing? (BTW - there's a significant change to API Gateway constructs coming imminently although this item is not addressed.)

[fargito]

The weird thing in the example I gave is that the SK = :v1 condition in the KeyConditionExpression uses a param named PK in the path (":v1": { "S": "$input.params('PK')" }). This would kind of seem like I mixed up my partition and sort keys.

My proposed change is to:

• add an optional resourceName argument to the construct
• if this resourceName is not defined, default to the partitionKeyName
• when adding the resource, use this.apiGateway.root.addResource("{" + resourceName + "}");
• then, say that for example, I have set resourceName: 'userId' as a construct argument, I'll be able to write

    readRequestTemplate: `{ \
       "TableName": "${dynamodbTable.tableName}", \
       "KeyConditionExpression": "PK = :v2 AND SK = :v1", \
       "ExpressionAttributeValues": { \
         ":v1": { \
           "S": "$input.params('userId')" \           <--- change here
         }, \
         ":v2": { \
           "S": "MY_VALUE" \
         } \
       } \
     }`,

which would be less confusing IMO.

I'll try and drop a PR to address this, WDYT?

[biffgaut]

We had put this on our list to implement, but will hold off if you want to give it a try. As we see it, there's a new optional attribute on the Construct props, resourceName. If supplied, this is used in place of partitionKeyName on line 249. It's also used in every input.params('${partitionKeyName}' statement, but "KeyConditionExpression": "${partitionKeyName} = :v1", \ statements remain unchanged. Your use case will still require a custom template, as you are swapping Sort Key for Primary Key.

This is only applicable to this construct, the default resource names on the other apigateway constructs are specific to the content (Records, Message, etc.). We'd want to see at least one more unit test and one more integration test.

Let us know if you want to take it on.

(re-reading this and your post, I guess it is pretty much exactly what you proposed above :-)

[fargito]

That's correct! I'll still need a custom template indeed

[biffgaut]

So just to clarify - will you be submitting a PR, or should we add it to our todo list?

[fargito]

I should be able to submit a PR at the beginning of next week!

[biffgaut]

Great - we'll watch out for it.