Proposal: integration for DynamoDB expression syntax

[tvanhens]

Perhaps this is a stretch, or there is a better way of accomplishing the same task, but having DyanamoDB expression arguments behave as functionless integrations would enable some interesting use cases while being able to benefit from TypeScript checking and syntax.

Desired Behavior

Query

// Ideal syntax for query
table.query((item) => {
  // Query requires a boolean response value
  return (
    item.type === "connection" && // filter expression to narrow type
    item.pk === `connection|${event.body.tenantId}` && // pk is always required in KeyConditionExpression
    item.version === "1" // filter expression
  );
});
// Transforms to:
await $AWS.DynamoDB.Query({
  Table: table,
  KeyConditionExpression: "#name2 = :val2",
  FilterExpression: "#name1 = :val1 and #name3 = :val3",
  ExpressionAttributeNames: {
    "#name1": "type",
    "#name2": "pk",
    "#name3": "version",
  },
  ExpressionAttributeValues: {
    ":val1": { S: "connection" },
    ":val2": { S: `connection|${event.body.tenantId}` },
    ":val3": { S: "1" },
  },
});

[thantos]

Some related ideas in here if you did see them: #106

[tvanhens]

I did not catch that one. I did a search but I glanced passed it because I assumed it was only scoped to the config of a table not the usage. Can close in favor of the linked issue if you'd prefer to track the work context there.

[thantos]

Could you write examples in relation to the table and the call in a function or sfn?

Very similar to what I wrote in #106 though

table.updateItem(item, (prev) => ({ ...prev, value: prev.value + 1 }));

Could you create a new issue (or re-use this one) with what you want the top level to look like? Personally I think they should be as clean like the event bridge ones.

bus
   .when(event => event.source === "lambda")
   .map(event=>({ name: event.detail.name}))
  .pipe()```

[tvanhens]

Can do.

Question on the event bus case. Do when and map collapse together to form one low-level resource (e.g. a filter rule)? Or, do they represent discrete resources with each one mapping 1:1 with a low-level resource?

Wondering because it might change how I think of the ideal API here.

[thantos]

Dynamo doesn't nessecarily need to be fluent, better if we can keep it as one closure. Limitations in the compilation target and the ability to compose with event bus drove the current design (cannot call two integrations, must filter then transform).

when creates the Pattern document and map adds a Input Transform to whatever is in pipe.

when can be chained together

when(event => event.source === "lambda").when(event => event["detail-type"] === "myType")`

This is the same as

when(event => event.source === "lambda" && event["detail-type"] === "myType")

whens can be re-used and no Rule is actually created until map or pipe is called.

const lambdaEvent = bus.when(event => event.source === "lambda");
const lambdaFailure = lambdaEvent.when(event => detail.status === "Failure");
const lambdaSuccess = lambdaEvent.when(event => detail.status === "Success");

lambdaEvent .pipe(someFunction);
lambdaFailure .pipe(someFunction);
lambdaSuccess .pipe(someFunction);

This would create 3 rules.

[tvanhens]

I updated the text with my ideal API. Unfortunately, I only have Query because I haven't been able to reason through a consistent way to collapse PutItem and UpdateItem into a consistent singular closure yet. Going to revisit your linked issue and will add additional examples as they start to crystalize.

[sam-goodwin]

I did not catch that one. I did a search but I glanced passed it because I assumed it was only scoped to the config of a table not the usage. Can close in favor of the linked issue if you'd prefer to track the work context there.

I think we are trying to move to a convention like the typescript repo where we add a keyword section to each issue along with tags.

We should probably have issue templates?