|
| 1 | +# V3 Changes and updates |
| 2 | + |
| 3 | +As part of the V3 update we are aiming to streamline and improve the following high level areas. |
| 4 | + |
| 5 | +- Network call optimisation |
| 6 | +- Backing store plugin architecture |
| 7 | + |
| 8 | +## Network Call optimisation |
| 9 | + |
| 10 | +There are many cases when an input string/file or array of `--token` can point to the same underlying token. |
| 11 | + |
| 12 | +e.g. |
| 13 | +```yaml |
| 14 | +db_user: AWSSECRETS:///app1/db|user |
| 15 | +db_password: AWSSECRETS:///app1/db|password |
| 16 | +db_port: AWSSECRETS:///app1/db|port |
| 17 | +db_host: AWSSECRETS:///app1/db|host |
| 18 | +``` |
| 19 | +
|
| 20 | +Given the above input passed into the CLI i.e. `configmanager fromstr -i above-config.yaml` |
| 21 | + |
| 22 | +This would result in 4 network calls to the underlying service, in this case the AWS Secrets Manager. |
| 23 | + |
| 24 | +The V3 update would fan in these 4 tokens into a single network call and then fan out back to a full map with the individual values for each of the look up keys. |
| 25 | + |
| 26 | +> NB: any token using a metadata annotation on any token would guarantee a unique call to the underlying service |
| 27 | + |
| 28 | +e.g.: |
| 29 | + |
| 30 | +```yaml |
| 31 | +db_user: AWSSECRETS:///app1/db|user |
| 32 | +db_password: AWSSECRETS:///app1/db|password |
| 33 | +db_port: AWSSECRETS:///app1/db|port |
| 34 | +db_host: AWSSECRETS:///app1/db|host |
| 35 | +db_host_2: AWSSECRETS:///app1/db|host[version=2] |
| 36 | +``` |
| 37 | + |
| 38 | +Even though `AWSSECRETS:///app1/db|host[version=2]` and `AWSSECRETS:///app1/db|host` are technically the same AWS Secrets Manager item, specifying the version requires two separate network calls. |
| 39 | + |
| 40 | +## Backing Store plugin architecture |
| 41 | + |
| 42 | +The current implementation of the backing stores is defined entirely within the configmanager source code which becomes part of the final staticly linked binary. In order to avoid the bigger size binary and **more importantly** avoid security alerts for libraries that are nothing to do with a backing store provider which is not used! |
| 43 | + |
| 44 | +Most probably, and most commonly, one would only use single or a combination of providers within the same Cloud for example. |
| 45 | + |
| 46 | +### Plugin Architecture |
| 47 | + |
| 48 | +There are a few options to choose from - terraform style provider plugins using gRPC. |
| 49 | + |
0 commit comments