cdk-dynamodb-expression

aereal/cdk-dynamodb-expression: DynamoDB expression builder for AWS CDK

AWS CDKでDynamoDBの式を書く時に便利なグッズ。

usageより:

import { DynamoAttributeValue } from "@aws-cdk/aws-stepfunctions-tasks";

    const builder = new ExpressionBuilder();
    builder.update`SET Executing = ${DynamoAttributeValue.fromBoolean(true)}`;
    const {
      updateExpression,
      conditionExpression,
      expressionAttributeValues,
      expressionAttributeNames,
    } = builder.aggregate();
    expect(conditionExpression).toBeUndefined();
    expect(updateExpression).toBe("SET Executing = :v0");
    expect(expressionAttributeNames).toBeUndefined();
    expect(expressionAttributeValues).toStrictEqual({
      ":v0": DynamoAttributeValue.fromBoolean(true),
    });

DynamoDBの式に属性の値をリテラルとして書くことはできず、プレースホルダを書き、プレースホルダと実際の値の辞書をそれぞれ与えるようになっている。

式に現れるプレースホルダは当然ユニークでなくてはならないけれど、シンボルテーブルの管理を自前でやるのもめんどうなのでtagged template literalを使うことで、式にそのまま値を埋め込んでいるような書き味なのがオシャレだと思う。

また、色気を出してプレースホルダの生成に使うカウンタをgeneratorで実装した。

go-dynamodb-attribute-conversions

aereal/go-dynamodb-attribute-conversions

AWS SDK for GoとAWS Lambda for Goの間でDynamoDB関連の型に互換性がないので変換するライブラリを書いた。

AWS SDK for Goにはdynamodbattributeという便利パッケージがあることに最近気がついて、たとえば UnmarshalMap は map[string]*dynamodb.AttributeValue をstructにUnmarshalしてくれる。 DynamoDBのO/Rマッパを意識したライブラリは世にいくつかあるけれど、個人的な用途ではこれとdynamodb/expressionというDynamoDBの式を組み立てる便利パッケージがあれば十分だと感じた。

ところでAWS Lambda for GoはLambdaのハンドラを書く時に便利な型も提供している。 eventsパッケージ以下にあるのがそれで、CodeBuildやKinesisから呼び出されるペイロードの型が定義されているので、それらを購読するLambdaハンドラを書く時はこの定義を使うと便利。

その中にもちろんDynamoDB Streamsを購読する時の型も定義されているけれど、これと前述のAWS SDK for Goの型に互換性がない。なので、Streamsを購読して何かするLambdaハンドラを書く時に、ペイロードにやってきたアイテムを構造体にUnmarshalする時にAWS SDK for Goの型に直さないといけない。

一対一対応しているので実装は大変ではないがちまちましているし、けっこうありがちなパターンっぽく、かつAWS Lambda for Goの型をSDKに寄せるP-Rは2年以上動きがなく、コメントのやりとりを見てもwon't fix感が漂っているので書いた。

go-httpretryafter

aereal/go-httpretryafter: Provides functions to parse Retry-After header.

Retry-Afterヘッダをパースして再試行して良い time.Time を返す関数を提供するライブラリ。

GoでHTTPリクエストを良いかんじに再送するライブラリはいくつかあるけれど、どれも一長一短で用途に合わなかったのでリトライ処理は自前で書くことにした。

そのためにRetry-Afterの仕様を調べたところ、実は絶対時刻と相対時刻の両方が指定できるので、これはアプリケーションの中で実装するにはちょっとめんどうだなと思い外に出した。

aws-cdk-apigw-documentation

aereal/aws-cdk-apigw-documentation: Collection of constructs for API Gateway Documentation parts.

AWS API Gateway v1のREST APIにはDocumentation PartというOpenAPIに準拠した追加のドキュメンテーション情報を与えることができるのだけれど、これのAWS CDK Constructsがないので書いた。

Documentation Partについてはちょっと前のメモもどうぞ: AWS API Gatewayのdocumentation partに関するメモ - Sexually Knowing

関係ないけれど命名規則がけっこうぶれている。aws-cdk-なのかcdk-なのか。