jensenak / fig Goto Github PK

Oh man. But how?

You know... tests should be in a separate directory, instead of bundled with the prototype code.

Should open and write a .env file which can be sourced in bash.

A value in the hierarchy may refer to another value elsewhere. There are two ways this might be done:

• The value itself is just a pointer to another value
• The value is itself a value, but contains a reference to another value that must be interpolated with the remainder

The second bullet point is out of scope here. For the prototype, we're only denoting a value as a type of "pointer" to another value. Interpolation comes later.

For example:

/dev/app/web/db_password = "#REF:/dev/db/db_password"
# The value above resolves to the content of 
/dev/db/db_password = "thepassword"

Value resolution must happen at the time the value is requested, not when the reference is written. The actual markup that denotes a reference doesn't have to be "#REF:". That detail is left to the implementation.

Between prototype and MVP phases, the primary features and functionality should be fairly locked down. Interfaces for main classes and methods should be locked down and documented.

Build a CLI mode with the following features:

• All commands are passed as an argument to [script-name]
• Commands supported for MVP:
  • Create a new value [ set ]
  • Read a single value [ get ]
  • Read all values at given branch [ export ]
  • Update value [ set, with "overwrite" prompt ]
  • Delete single value [ delete ]
  • Delete branch and all contained values [ delete, with "whole branch" prompt ]
  • "-f" flag to skip prompts
  • "-n" flag to disable recursion (single level exports)
  • "-v" flag to increase log level
  • "-o" flag to change output filename [ default .env ]

Right now, all testing is focused on acceptable features and functionality. Performance will be a major concern for larger trees. Perf tests should help identify poorly designed functions with O(n^2) or worse performance.

Prototype was built backwards, with recursive functionality retrieving values for more specific keys, rather than getting all values inherited at a given level of specificity.

Also, recursive should be default, with an option to only retrieve keys actually set at the given level.

Prototype phase in particular generated a wide variety of variable names and function names. Now is a good time to refactor this application to use more consistent variable naming inside functions and methods. This makes it easier for maintainers down the line.

For the sake of discussion, a hierarchy looks like a filesystem. Tiers are delimited with a slash "/", and more tiers in a path represent a more "specific" value. For example:

/ # This is a root
/name = "bob" # A global value (at the root) with the key "name" is set to "bob"
/dev/name = "alice" # The "name" in the "dev" space is set to "alice"

# If the user requests the value
/qa/name
# "bob" is returned, because it is the most specific value that has been set for /qa/name
/dev/name 
# returns "alice", however, since the more specific value overwrites the less specific one.

In implementation, the hierarchy may not necessarily involve "/" delimiters. This is only a feature of the presentation.

Essentially this hierarchy behaves like a dictionary. Each key may contain either a fixed value, or may contain a tier of the hierarchy (like a dict in a dict).

Acceptance Criteria:

• Crud client for AWS SSM Parameter store
• Performs hierarchy lookup/resolution functions against the same