The purpose of Dyno

[mcwhittemore]

I was talking with @rclark about the purpose of Dyno vs the javascript object friendly AWS client last night and wanted to document what we said to help us keep focused on the new goals of this project since a large part of the original goal has been solved by AWS themselves.

1. Support reading from one region and writing to another
2. Better support for streaming
3. Better support for bulk read and write actions

I'd like to rework the README to clarify these goals. Is there anything else we should cover?

I'd also like to take a look at stuff dyno does that doesn't fall under the stated goals and talk about removing the functionality or being explicit that this is a goal. One thing Dyno does now that isn't mentioned above is provide cli support.

[rclark]

A lot of the usage is identical, by design. You've hit on a few of the points here, but also missed a few:

• dyno CLI pairs nicely with some outputs from https://github.com/mapbox/dynamodb-replicator
• adds an option to ask for X pages worth of query/scan data
• easy de/serialization between dynamodb-style objects and native JS objects
• table creation/deletion that returns when the action is complete and the table is ready or gone, not when the API call responds

[mcwhittemore]

dyno CLI pairs nicely with some outputs from https://github.com/mapbox/dynamodb-replicator

So... isn't the cli something dynamodb-replicator should ship? I could also see a dyno-cli lib, I'm just not really sure how much value there is here. Outside of taking backups and filling up a new db with them, what do people use the cli for? Do we really need a cli with complete functionality?

adds an option to ask for X pages worth of query/scan data

I think this pairs well with the 'make bulk reading better' use case.

easy de/serialization between dynamodb-style objects and native JS objects

Does the AWS SDK not provide it? Is this not just a pass through?

I do use this when writing tests for lambda functions that work as dynamodb triggers.

table creation/deletion that returns when the action is complete and the table is ready or gone, not when the API call responds

Hmmm... so another goal is to provide a clearer return state to users. Are there other cases where we should be doing this?

[knksmith57]

Chiming in here considering the ongoing discussion in #135:

There are three features of this library that make it compelling for our use:

1. native JS object serialization / deserialization
2. table creation/deletion complete wrappers
3. bulk operations heavy lifting

[rclark]

Outside of taking backups and filling up a new db with them, what do people use the cli for?

I think that these two use-cases are the ones to support.

Is [de/serialization] not just a pass through?

It is non-trival: see https://github.com/mapbox/dyno/blob/master/lib/serialization.js

[mcwhittemore]

Outside of taking backups and filling up a new db with them, what do people use the cli for?

I think that these two use-cases are the ones to support.

@rclark - why not drop this support here and move it to the replicator?