<commit_before># Distributed Config (discfg)

**NOTE** This project is under active development and is not considered production ready.
In fact, under no circumstances should you use this in production. However, I always appreciate
feedback. The goals of this project are constantly changing and while I first compared and 
contrasted it with etcd, it's quickly departing from the same feature set.

discfg is being created for a very simple reason. Shared application configuration and state 
within AWS services. The expectation is that you're developing some distributed application. 
Perhaps a series of micro/services.

In the future, maybe it will have the ability to run independent of AWS. However, the first
cut of this will heavily rely upon AWS. This is for convenience and cost. The drawback is 
speed and consistency. Solutions like etcd will ultimately be faster and better geared for
systems level needs. discfg is looking more toward applications.


------

A distributed configuration service built on top of Amazon Web Services. Specifically, it uses 
Lambda, DyanmoDB, and API Gateway to access it all. Though it can also be used via command line.


### Quick Example Usage

Assuming you built the binary to ```discfg``` and you have your AWS credentials under ```~/.aws``` 
because you've used the AWS CLI tool before and configured them...

```
./discfg create mycfg    
./discfg use mycfg    
./discfg set mykey '{"json": "works"}'    
./discfg set mykey -d file.json
```

That should create a configuration for you (a table in DynamoDB - US East region by default). 
The second command there should have set a key called "/mykey" at the root level.

Note: If you did not want to call the ```use``` command or if you need to work with multiple configurations,
you can always get and set keys by passing the configuration name. So the following ```set``` command is
the same as the one above:

```
./discfg set mycfg mykey '{"json": "works"}'
```

Also note that the slash is optional. All keys without a forward slash will have one prepended automatically. 
That is to say they will be at the root level. Now to retrieve this value:<commit_msg>readme update<commit_after># Distributed Config (discfg)

**NOTE** This project is under active development and is not considered production ready.
In fact, under no circumstances should you use this in production. However, I always appreciate
feedback. The goals of this project are constantly changing and while I first compared and 
contrasted it with etcd, it's quickly departing from the same feature set.

discfg is being created for a very simple reason. Shared application configuration and state 
within AWS services. The expectation is that you're developing some distributed application. 
Perhaps a series of micro/services.

In the future, maybe it will have the ability to run independent of AWS. However, the first
cut of this will heavily rely upon AWS. This is for convenience and cost. The drawback is 
speed and consistency. Solutions like etcd will ultimately be faster and better geared for
systems level needs. discfg is looking more toward applications.


------

A distributed configuration service built on top of Amazon Web Services. Specifically, it uses 
Lambda, DyanmoDB, and API Gateway to access it all. Though it can also be used via command line.


### Quick Example Usage

Assuming you built the binary to ```discfg``` and you have your AWS credentials under ```~/.aws``` 
because you've used the AWS CLI tool before and configured them...

```
./discfg create mycfg    
./discfg use mycfg    
./discfg set mykey '{"json": "works"}'    
./discfg set mykey -d file.json
```

That first command creates a configuration for you (a table in DynamoDB - US East region by default). 
After that you can set keys from values passed to the CLI or from a file on disk. All values ultimately 
get stored as binary data, so you could even store (small - DynamoDB size limits) images in there if 
you really wanted to.

Note: If you did not want to call the ```use``` command or if you need to work with multiple configurations,
you can always get and set keys by passing the configuration name. So the following ```set``` command is
the same as the one above:

```
./discfg set mycfg mykey '{"json": "works"}'
```

Also note that the slash is optional. All keys without a forward slash will have one prepended automatically. 
That is to say they will be at the root level. Now to retrieve this value:
{'fraction_non_alphanumeric': 0.061065299754847334, 'fraction_numerical': 0.0, 'mean_word_length': 4.037037037037037, 'pattern_counts': {'":': 4, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1129839', 'n_tokens_mistral': 1134, 'n_tokens_neox': 1073, 'n_words': 707}