When using the serverless framework it is considered good practice to use SSM Parameter Store for configuration (https://serverless.com/framework/docs/providers/aws/guide/variables/#reference-variables-using-the-ssm-parameter-store).
I feel like using SSM would be preferable for secret credentials to the current Dotenv system since there isn’t any obvious solution for how to sync gitignored .env files across a large number of developers. Also it doesn’t provide a solution for sharing the same configuration across multiple Ruby on Jets projects which can come in handy.
As I see it there might be two approaches for implementation:
- Do it like serverless - interpolate configuration at deploy time before setting lambda function environment variables
- Look up the parameter store at run time - this has added benefits such as allowing to change parameters / rotate credentials without re-deploying all related functions
Number 1 is probably fairly straight forward to implement while number 2 would imply some deeper thought into configuration management / caching of variables etc but could result in a more seamless experience.
An article on this subject and how it relates to serverless can be found here: https://hackernoon.com/you-should-use-ssm-parameter-store-over-lambda-env-variables-5197fc6ea45b (the author concludes that it would have been preferable if serverless would have allowed run time lookup instead of deploy time)
Do you have any thoughts on this in general? If we had build time / deploy time hooks it might be possible to add SSM support as a plugin but I really think this should be a core feature of Ruby on Jets considering it’s a core service in the AWS ecosystem. It would also be more in line with how deployment in most frameworks is currently done where you expect remote configuration to live server side and be decoupled from the local environment.