dynamodb-toolbox
dynamodb-toolbox copied to clipboard
Migrate to aws-sdk-js-v3 document client
Migrating from aws-sdk-js-v2 to aws-sdk-js-v3. (https://github.com/jeremydaly/dynamodb-toolbox/issues/155) It uses DynamoDB Document Client v3.
Will this be merged anytime soon?
It's been months since the PR's been created. I don't think it's getting merged anytime soon. :(
Waiting for this one as well..
Is there any help needed with this work?
Let's get this one merged v3 drastically reduces bundle size for serverless apps on lambda 🙌
@glcheetham technically you don't need to bundle v2 in your code since it is included in lambda function environment by default 🤷♂️
@glcheetham technically you don't need to bundle v2 in your code since it is included in lambda function environment by default 🤷♂️
True, but worth knowing that it's an 'old' (6 months since release at time of writing - v2.1001.0) version, so make sure you peg your code to the same version to avoid any unexpected issues.
This merge has been on hold because of the work on v0.4. This is now a high priority item, but will need a major refactor. Working with other collaborators to get this compatible with v0.4.x.
@jeremydaly when is the timeline to get this bad boy in? Do you foresee it being compatible with the current dynamo tool box API or will it introduce breaking changes.
Please note that DAX is not supported by aws s3 - so ideally dynamo toolbox should baked in the ability to switch easily between v2 and v3
Lambdas Node.js 18 runtime ships with sdk v3, would be nice if this would be merged soon
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
Lambdas Node.js 18 runtime ships with sdk v3, would be nice if this would be merged soon
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
At the moment I'm focusing on getting all the features/bug fixes in the issues section done, mostly because v3 is not backwards compatible, as far as I know.
Let me know if I'm wrong, would love to add support for v3
V3 has some backwards compatibility interface but is not recommended to use it because it does not take advantage of the modularity of the new API
dynamodb-onetable does support both V2 and V3 via a small abstraction layer. Maybe this idea could be useful here as well.
@shishkin Thanks for calling this out!
Anyone else looking for a good DynamoDB library with Deno, I can verify that dynamodb-onetable is working great with Deno 1.28 by way of these three imports and following the dynamodb-onetable documentation for setting up the connection, table, model, etc.
... in import_map.json
"@aws-sdk/client-dynamodb": "https://esm.sh/@aws-sdk/[email protected]",
"dynamodb-onetable": "https://esm.sh/[email protected]",
"dynamodb-onetable/Dynamo": "https://esm.sh/[email protected]/Dynamo"
...
Looks like a great abstraction, hopefully dynamodb-toolbox will benefit from it too!
dynamodb-onetable does support both V2 and V3 via a small abstraction layer. Maybe this idea could be useful here as well.
Great idea :) If anyone wants to open a PR for this let me know. If not, I'll try to implement it soon but a bit busy in the next few days 😢
@shishkin Thanks for calling this out!
Anyone else looking for a good DynamoDB library with Deno, I can verify that dynamodb-onetable is working great with Deno 1.28 by way of these three imports and following the dynamodb-onetable documentation for setting up the connection, table, model, etc.
... in import_map.json "@aws-sdk/client-dynamodb": "https://esm.sh/@aws-sdk/[email protected]", "dynamodb-onetable": "https://esm.sh/[email protected]", "dynamodb-onetable/Dynamo": "https://esm.sh/[email protected]/Dynamo" ...
Looks like a great abstraction, hopefully dynamodb-toolbox will benefit from it too!
Adding support for Deno is a great idea and should be fairly easy to implement afaik, will add that as a card on our milestones board.
Really keen to finally see this PR get over the line. Is there anything you need help with?
Really keen to finally see this PR get over the line. Is there anything you need help with?
I'm not sure whether to push it before closing the rest of the open issues or not. This change would prevent people who are using the previous versions from enjoying the benefits of bugfixes/features that will be done based on the current implementations.
V1, will include SDK v3 support out of the box, along with a big re-write of most of the current code.
At the same time, we could make a wrapper above the SDK v3 client, like mentioned in one of the above comments. If anyone wants to create a PR for this, go for it. Unfortunately, I don't think I'll be able to work on this and test it thoroughly before mid-ish January.
What is the timeframe for v1? That might answer the question..
If it's less than 6 months, I'd say we wait. If it's more then we build a wrapper as discussed.
What is the timeframe for v1? That might answer the question..
If it's less than 6 months, I'd say we wait. If it's more then we build a wrapper as discussed.
There's no set date at the moment, but I'm hoping and feel it will be in the 6 months zone and not more. (this is purely my estimation)
Hi, any news with this PR ?
Hey everyone, due to AWS's decision to make AWS SDK v2 go into maintenance mode soon, I'll be going over this PR asap and get this merged OR migrate the latest codebase to use V3. Not sure if later today but will try my best to do it this week.
@naorpeled How close is this next update out of interest?
@naorpeled How close is this next update out of interest?
I hope we'll be able to release it sometime during this weekend or next week 🙏
Hey everyone, this was released in v0.8 😎 !