Table Configuration Export about dynamodb-toolbox HOT 8 OPEN

I can't see a case where you would want this library to be the single point of truth for defining a table structure.

The single point of truth should be the cloud formation, and this library should conform to that definition - not the other way around.

Imagine your above scenario, where your infrastructure team wants to implement streams off of the table for auditing concerns, or implementing point in time backup, or anything else that dynamodb can do.. This has nothing to do with the application your development team is creating, but they would have to:

• Ensure this library supports it, and if not implement it
• Code it into the application.

Would you advocate that this library implement the functionality to expose this?

Maybe your dev team is no more and you only have an infra team? So now we have to stand up a project for this and hire developers.

Maybe there is a case for deriving dynamo-toolbox from cloud formation, but definitely not the other way around.

I'm interested to hear your use cases but I just can't find any myself.

Cloud formation is a very powerful tool which this library shouldn't be (and isn't) trying to replace.

from dynamodb-toolbox.

@darbio interesting thoughts, It now sounds like I was driving myself in wrong direction, then may be dynamodb-toolbox should allow importing existing schema instead of exporting it. However my point still stands (was inverted) 😛 we need single source of truth. Thanks.

from dynamodb-toolbox.

I think this is YAGNI. It takes 2 seconds to write a YAML on table definition for Dynamodb.

from dynamodb-toolbox.

@darbio you are right, but dynamodb-toolbox table config and actual table schema can get out of sync very easily, I think It is a good idea to have dynamodb-toobox export schema and use that when provisoning table usign cfn. (ps. single source of truth for table schema)

from dynamodb-toolbox.

Which bits get out of sync?

Once you have your basic table definition (pk, sk and gsi's) adding more gsi's is a simple addition to the cloud formation.

Having it as an explicit step makes you think about why you are adding the gsi.

A table that has just one gsi can support many access patterns. I'd be making sure I was thinking really hard to justify adding further gsi's before I did it...

from dynamodb-toolbox.

@darbio Yes agree, but there dynamodb-toolbox table schema stills lives separately to actual table definition. There are chances that one might forget to update other. Or to be more specific, imagine a case where there are different teams managing ops and actual server code, having dynamodb-toolbox export schema can simplify things for both teams, as ops team can simply rely on table schema exported by dt table.

But it's just an opinion. I would personally like to not repeat myself, even if it is just couple of GSIs and primary keys. 🙂

from dynamodb-toolbox.

Seeing as CFn is either JSON or YAML it shouldn't be too hard to parse this in your code and load the table dynamically, if you really think it's worth the effort, maintenance and computational overhead, for something that shouldn't change much (if ever in a minor version bump).

I'd suspect that the time might be better spent coding business value rather than SPOT nirvana.

from dynamodb-toolbox.

right may be this should be marked low priority then, good to have but not something we need rn.

from dynamodb-toolbox.