Update repository structure

[tebanieo]

This repository has been growing over the years with examples from different programing languages and some extra functionality.

I think the README.MD should be updated as it redirects readers to different top level folders that don't follow a structure.

I need your feedback about this folder structre that I am proposing below:

• infrastructure_as_code: The folder will include all the templates used to deploy DynamoDB to an AWS account
  • cloudformation: One folder per solution that includes a deployable cloudformation template, the project MUST have a README.MD file that explains the need of the template.
  • cdk: One folder per solution that includes a deployable CDK project. The project MUST have a README.MD file that explains why this project is important, the pre-requisites and how to deploy it.
  • security: IAM policies examples in JSON format, optionally you can include CDK and cloudformation examples.
• workshops: All the workshops created in this repository, one workshop per folder with a brief description, this folder should have a README.MD file explaining this in detail. A workshop is intended to be a self service
• schema_design: This folder contains all the examples and sample code that promotes schema design libraries. README.MD is needed here.
• deprecated: Any content that is not longer useful/valid.
• local_development: This is the folder that will include local development instructions.
• sdk-examples: This directory will replace the DynamoDB-SDK-Examples.
  • One folder per programing language. The initial README.MD needs re-work to keep up with all the examples that we have in this folder.
  • Ideally all the functionality from one language should be supported on another, please aim for consistency over edge cases, if your example is an edge case, create a table at the bottom explaining why it is an edge case.
  • Categories should be updated, and all the examples need to be something different than the documentation, they should include exception handling, pagination and more "real-life" approach.
  • Inside each language folder I recommend to have top level versions ex: javascript/v3 or javascript/v2, followed by a control_plane, data_plane folder for example:
  • javascript
  • v3
    • data_plane
    • table_operations
      • scan ...
    • stream_operations
      • ...

Code quality:

• Use the same dataset for all the examples! This could mean either to have the sample dataset under the language folder, for example dataset.json or just use the same values for your examples.
• Examples must be self contained, if you need to create different files for the same example, your example is too big and it needs re-scope.
• File names, variables should follow language preffered structure, ex: snakecase vs camelcase.
• Use README.MD to provide useful explanations for your code, let the code be the code.

[tebanieo]

After discussing internally with @arjanschaaf, we are suggesting to mode the workshops folder out of this repository to the amazon-dynamodb-labs and use it as a central place.

[mslshao]

Great proposal overall. I have two suggestions:

• Instead of "deprecated" I would recommend calling this "archived", or something along the lines of "no longer supported". We don't want to give the impression that we're updating/maintaining those previous code samples, but until the code samples are actually obsolete (or straight up just don't work, and we're not going to fix them), I think it'd be a mistake to disavow them completely.
  • Whenever they stop working (if the SDK version gets updated, for example), then we can simply remove them. I think having a README.md in that folder explaining "these code samples may not work and are preserved for historical archival purposes" should be sufficient as a "warning" for users who randomly happen upon them.
• "create a table at the bottom explaining why it is an edge case." -- I think we should provide the "base" table of what is already expected to be included, so that anyone contributing doesn't have to spend more than a few minutes outlining their "edge case". If they have to build that table from scratch, it's a barrier to entry (and somewhat of a waste of time, since it's technically "boilerplate" formatting).