Skip to content

Design Overview

This document outlines the overall design of the tool, including how AWS requests are managed and stored, as well as details on environment variables, templating, authentication, and CLI commands.

  1. Collections: Group related actions together.
  2. Environments: Define variables for different deployment stages (local, dev, prod).
  3. Actions: Individual AWS serverless tasks (Lambda invoke, SQS send, etc.).
  4. Variables: Dynamic value replacement within actions.
  5. Authentication: Seamless AWS credential management.
  6. CLI Commands: Powerful terminal interface for execution and management.

Designed to be Git-friendly, the tool stores collections in a directory structure. All metadata and actions are stored in TOML files.

Collections are the top-level entity.

  • Represented as directories (the directory name is the collection name).
  • Contain a myna.toml file with collection metadata.
  • Can store a hierarchy of actions in subdirectories or directly within the collection directory.

Environment variables are managed using .toml configuration files: All environment files are stored under environments directory of the collection root.

  • dev.toml
  • local.toml
  • prod.toml
my-collection
├── myna.toml
├── environments
│ ├── dev.toml
│ ├── local.toml
│ └── prod.toml
├── s3-upload.toml
├── lambda-invoke.toml
├── sqs-send-message.toml
├── sns-publish.toml
├── eventbridge-send-event.toml
├── coreapis
│ ├── create-lambda.toml
│ ├── update-lambda.toml
│ ├── delete-lambda.toml
│ └── invoke-lambda.toml
├── eventtesting
│ ├── action2.toml
│ └── action3.toml
└── cleanup
└── action3.toml

All collection metadata is stored in a myna.toml file in the collection directory. The collection metadata contains:

  • version
  • kind
  • description
  • vars
  • aws
version = "1.0"
kind = "collection"
description = "My collection description"
[vars]
MY_VARIABLE = "my_value"
MY_OTHER_VARIABLE = "my_other_value"