Timeline on migrating from aws-sdk-js-v2 to aws-sdk-js-v3

[tommy921092]

This is not an issue. Just want to know is there a timeline for the migration from v2 to v3 library as it gives some performance improvement due to bundle size reduction. Thanks!

[jeremydaly]

Hi @tommy921092! I don't have a timeline, but I think we're going to need to drop support for v2 and the DocumentClient and use v3 with marshall/unmarshall utils. It's a shame that the new DocumentClient isn't compatible.

[revmischa]

I'm using ddb-toolbox with Lambda and CDK. ddb-toolbox is the only thing holding me back on using the v2 SDK, and it causes issues with things like XRay instrumentation because it's extremely inefficient in the v2 SDK.

[k-atama]

I SWEAR I searched for an open ticket on this, but didn't see this until just now. Apparently I'm bad at searching.

I'm going to copy / paste the contents of my almost-ticket below in case it's useful for anything, but tl;dr; I was also / am also looking for v3 support. I'm new to DynamoDB and new to dynamodb-toolbox so not sure I'm a great fit to help with this at this point, but am happy to help if I can!

---

I'll preface this by saying I'm a bit confused as to the "right" way to use the AWS JS SDK in different situations - sorry if this is totally off the mark with this issue.

My understanding is that using the v3 AWS SDK will reduce bundle sizes and is preferable to installing the entire aws-sdk. The docs here recommend using the "full" aws-sdk from what I can tell:

// Require AWS SDK and instantiate DocumentClient
const DynamoDB = require("aws-sdk/clients/dynamodb");
const DocumentClient = new DynamoDB.DocumentClient();
...

I spent a few minutes trying to figure out how / if I could use the new-fangled and more granular packages, but didn't have much luck. It seems that Table.js looks for certain properties / options, and the things I tried didn't quite fit the bill:

import { DynamoDBDocument } from '@aws-sdk/lib-dynamodb';

This gives Table.js the put, delete, update, and get properties it's looking for, but the docClient.options!.convertEmptyValues property doesn't exist on DynamoDBDocument it seems, so this fails.

import { DynamoDB } from '@aws-sdk/client-dynamodb';

DynamoDB, to a newbie, seems to have a similar API in that it has methods like putItem (vs put), getItem (vs get), etc, however of course putItem !== put, so this also doesn't work with the checks mentioned above in Table.js.

For what it's worth, The docs from AWS (link is to the npm docs) mention the unmarshalling options that can be passed as constructor arguments that the Table class references (albeit in a completely different place!).

[naorpeled]

Hey @tommy921092, as @jeremydaly mentioned, we don't have a timeline for that atm but I can promise you it's going to be worked on asap, I want to finalize some features before doing so but will update everyone (probably through discussions) once I start working on it.

I'll be closing this issue for now because it's kind of a duplicate of another one.