Comparsion with DynamoDBToolbox about dynamodb-onetable HOT 1 CLOSED

Thanks for the question. We should enable GitHub discussions for these.

OneTable was extracted from a production system where it was developed and evolved for over a year. This repo is very recent and watches take time to build. We are aggressively pushing the code forward and have a suite of enhancements and tools coming like our migration CLI and a GUI to view and manage DynamoDB on a logical / entity level.

Regarding TypeScript: you can absolutely use OneTable with TypeScript. OneTable is written in JavaScript (esnext). We don't provide "typed" objects (yet), but we are investigating generating these from the schema.

The code base is small and very readable. We've focused mostly on the core and the OneTable schema which is much richer in describing attributes that a simple type system can do. Adding TypeScript definitions is high on our todo list. But you can use OneTable immediately and this will be an easy update. Making the Schema the center rather than just the type, allows richer modeling tools to be build. We are just at the start of this evolution in creating these tools.

Differences?

I'm not sure I can give a complete comparison grid, but here are a few interesting items:

• OneTable has a more evolved schema with validations, unique attributes, default values, etc.
• OneTable is fully validating on writes & reads. Attributes have validations and OneTable picks out the real attributes and only reads / writes these. This really helps keep your database clean.
• A more refined API resulting from the year in production before release while evolving and cleaning up the API.
• Templated key management from strings or functions. This uncouples keys from attributes.
• Natural "where" clause for queries that are mapped onto conditional and filter expressions.
• Transform functions on read / write to store data in alternate formats.
• Transparent auto-follow for GSIs that project only keys to retrieve primary items.
• Migrations and migration CLI. These are really helpful when evolving DynamoDB designs.
• Flexible API with Entity and Factory level APIs. i.e you can do: Account.get() or Table.get('Account')
• Cross-cutting contexts for supplying attributes out-of-band. Useful for PK/SK components that come from authentication. A request auth may provide an accountId which can be provided via a context instead of the API params. This really helps security and accidental security holes.
• Integrated logging
• AWS V3 support
• A high level API that allows conditional expressions to be used with get, remove, update.

from dynamodb-onetable.