Add support for AWS SDK v3 (`@aws-sdk/client-dynamodb`)

[moltar]

Would be great to have support for AWS SDK v3.

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

const client = new DynamoDBClient({})

Thanks!

[tywalch]

I'll begin taking a look at this, thank you. As a stop gap, the .params() might be useful in the short term.

[tywalch]

Something like this should also work in there interim:

import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { 
  DynamoDBDocumentClient, 
  PutCommand,
  GetCommand,
  ScanCommand,
  QueryCommand,
  UpdateCommand,
  DeleteCommand,
  BatchGetCommand,
  BatchWriteCommand,
} from '@aws-sdk/lib-dynamodb'

const clientV3 = DynamoDBDocumentClient.from(new DynamoDBClient({}));

class DocumentClientWrapper {
  client: DynamoDBDocumentClient;
  constructor(client: DynamoDBDocumentClient) {
    this.client = client;
  }
  get(params: any) {
    return {
      promise: async () => {
        const command = new GetCommand(params);
        return this.client.send(command);
      }
    }
  }
  put(params: any) {
    return {
      promise: async () => {
        const command = new PutCommand(params);
        return this.client.send(command);
      }
    }
  }
  update(params: any) {
    return {
      promise: async () => {
        const command = new UpdateCommand(params);
        return this.client.send(command);
      }
    }
  }
  delete(params: any) {
    return {
      promise: async () => {
        const command = new DeleteCommand(params);
        return this.client.send(command);
      }
    }
  }
  batchWrite(params: any) {
    return {
      promise: async () => {
        const command = new BatchWriteCommand(params);
        return this.client.send(command);
      }
    }
  }
  batchGet(params: any) {
    return {
      promise: async () => {
        const command = new BatchGetCommand(params);
        return this.client.send(command);
      }
    }
  }
  scan(params: any) {
    return {
      promise: async () => {
        const command = new ScanCommand(params);
        return this.client.send(command);
      }
    }
  }
  query(params: any) {
    return {
      promise: async () => {
        const command = new QueryCommand(params);
        return this.client.send(command);
      }
    }
  }
  createSet(value: any) {
    if (Array.isArray(value)) {
      return new Set(value);
    } else {
      return new Set([value]);
    }
  }
}

// client compatible with ElectroDB:
const client = new DocumentClientWrapper(clientV3);

[moltar]

Thanks Tyler, I'll give it a shot!

[ShivamJoker]

Any updates on this?

[tywalch]

I have been traveling frequently for the past few weeks and haven't had a chance to get this in. This is still on my radar and I am hoping to have more news on it soon.

[tywalch]

@ShivamJoker @moltar I have just merged and published v3 support in version 1.7.0! Please let me know if you have any issues when using the v3 client and I will make it priority to resolve your issues 👍

[ShivamJoker]

Thanks a lot I'll try it. Also I am using CDK so should I just make a table and your library will add GSI based on schemas?

[moltar]

Nice one @tywalch!

I still haven't had a chance to try this package out 🙈

Maybe this will give me a boost!

[moltar]

Btw, should @aws-sdk/lib-dynamodb be a peer dep?

Because this will increase bundle sizes for everyone, even if they do not use the v3 SDKs.

These v3 SDKs are quite bloated, unfortunately!

https://bundlephobia.com/package/electrodb@1.7.1

[ShivamJoker]

@moltar so are there any benefits of using V3 with electrodb? In terms of performance

[moltar]

Pros:

• Future-proofing. The end of support for v2 will probably be announced soon, since v3 has been out for a while. And other languages had already EOS announced.
• Native TypeScript support, without @types/*
• It is mostly codegen'ed from standard definitions, which ensures that all APIs are compatible
• Modular (use only what you need)
  • v2 is a heavy dep (if you bundle) (3MB). In v3, take a few common clients, and it'll be ~ 1-2MB and there is a TON of room for them to improve this still. The code is not yet well optimized for bundling.

Cons:

• Not available in the Lambda environment. (Although this was an anti-pattern anyways, and was not recommended to be used that way.)
• Less stable and less battle-tested.

[ShivamJoker]

Got it. Thank you

On Mon, Mar 21, 2022, 11:19 AM Roman @.***> wrote:

Pros:

• Future-proofing. The end of support for v2 will probably be announced soon, since v3 has been out for a while. And other languages had already EOS announced.
• Native TypeScript support, without @types/*
• It is mostly codegen'ed from standard definitions, which ensures that all APIs are compatible
• Modular (use only what you need)
• v2 is a heavy dep @.**> (if you bundle)* (3MB). In v3, take a few common clients, and it'll be ~ 1-2MB and there is a TON of room for them to improve this still. The code is not yet well optimized for bundling.

Cons:

• Not available in the Lambda environment. (Although this was an anti-pattern anyways, and was not recommended to be used that way.)
• Less stable and less battle-tested.

— Reply to this email directly, view it on GitHub https://github.com/tywalch/electrodb/issues/99#issuecomment-1073505724, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFVA4NVGN3WTG2ZSZZO3GX3VBAEVNANCNFSM5I3WEVXA . You are receiving this because you were mentioned.Message ID: @.***>