Request Collections

Request Collections are one of Dynomate's most powerful features, allowing you to group related DynamoDB operations together and execute them in sequence. This goes beyond what's possible with traditional DynamoDB clients by enabling complex workflows like data migrations, batch updates, or multi-step data retrieval processes.

Beyond Simple Queries

In real-world scenarios, you often need to run multiple queries at once, retrieving data that's stored across several entities within a single table (single-table design) or across multiple tables. Rather than manually copying keys from one query to use in another or writing custom scripts, Dynomate's Request Collections provide a powerful interface for these complex operations.

Creating Collections

As shown in the demo, collections in Dynomate are organized in folders in the sidebar. Here's how to work with them:

  1. Collections are accessible from the sidebar where they're grouped into folders
  2. In the demo, the presenter navigated to the "Sam" folder to create a new request
  3. When you open a collection or create a new request, it appears in a new tab

The demo showed how requests open in tabs just like tables do, maintaining Dynomate's consistent tab-based interface across different features.

Designing Requests

Each request in a collection represents a single DynamoDB operation. Dynomate supports all major operation types:

  • Query - Find items using partition key and optional sort key conditions
  • UpdateItem - Modify specific attributes of an existing item
  • PutItem - Create or completely replace an item
  • DeleteItem - Remove an item from the table
  • GetItem - Retrieve a single item by its key
  • Scan - Search entire tables with optional filters
  • BatchGetItem - Retrieve multiple items in a single operation
  • BatchWriteItem - Write or delete multiple items at once

To add a request to your collection:

  1. Open or create a collection
  2. Click "Add Operation" to add a new operation to your request
  3. Give your operation a descriptive name (e.g., "user_profile", "user_order")
  4. Select the operation type (Query, Update, etc.)
  5. Select the table ARN (you can choose from previously imported tables)
  6. Configure the operation parameters (partition key, sort key, etc.)
  7. Save the operation
  8. Add more operations as needed

Each operation within your request appears in a separate section, allowing you to manage multiple related operations in a single view. The operation name is important as it will be used when referencing results in subsequent operations.

Chaining Operations

The real power of Request Collections comes from the ability to chain operations together, using the output of one request as input to another.

For example, you might:

  1. Query a table to find a user profile with an email address
  2. Use that email to query an email logs table
  3. Use other user attributes to query additional related data like orders or activity

To reference the output of a previous request, use the special syntax ${operation_name.items[0].field_name} in your request configuration. Dynomate supports deep path traversal for extracting specific fields from complex objects.

Real-World Example

In the following scenario, we query a user profile first, then use their email address to find their email logs:

  1. First operation (named "user_profile") queries a user from the user details table
  2. Second operation (named "user_emails") uses ${user_profile.items[0].email} as the partition key
  3. When executed, the second operation automatically uses the email address returned from the first operation

This approach eliminates the need to manually copy values between queries or write custom scripts for related data lookups.

Saving & Organizing

The demo showed how to save and organize your work in Dynomate:

  • Saving Operations - Each operation can be saved individually within a request
  • Renaming - You can rename requests (as demonstrated with "demo user info")
  • Folders - Collections are organized into folders for easy access

In the demo, we saw how the presenter saved each operation after configuration and also renamed the request to give it a more descriptive name.

Sharing Collections

Sharing Request Collections with your team creates a consistent way to interact with your DynamoDB data across your organization. Dynomate provides multiple sharing options:

  • Export to JSON - Export collections to a JSON file that can be shared and imported by others
  • Version Control - Store collection files in your Git repository alongside your application code
  • Variables - Use variables to make collections work across different environments and AWS accounts

When combined with Variables, collections become even more powerful, as they can be designed once and run against different environments by simply changing variable values.

Local-First Approach

All Dynomate data, including your collections and requests, runs and is saved locally in your file system. Nothing is sent to or saved in any cloud service. This local-first approach ensures complete control over your data and enables you to commit collections to Git for version control and team collaboration without introducing external dependencies.