Hacker News Reader

Comment by nthj | Hacker News Reader

Nice! I had the same pain point and worked something up a few weekends ago. [1] I may look into integrating some of my ideas into Claudia.js, although "I like CoffeeScript" may not be in line with where the author is headed.

Most of my efforts went into integrating Amazon's Key Management Service into the local development and S3 deployment process. (One of the first Lambda functions I wanted needed to talk with GitHub, Slack and some other APIs, so encryption of access tokens seemed a given.) I'd be curious if the author has run into this situation or already had thoughts about how to approach this.

[1] https://github.com/twobyfourio/cheese-grater

View on HN

So for Shepherd (https://github.com/bustlelabs/shepherd) we copy in an env.js file on deployment to lambda that has all the env variables. Stage Variables are good, but there is a gotcha. If you are using them to establish connections (external service, DB, etc) you only get access to them inside the function body. Might not be the biggest issue for some people but I like to have everything loaded and connections established when the lambda function is loaded by the AWS parent process rather than on actual function execution.

I like that the name Cheese Grater gets clarified with the README and I instantly got it and chuckled.

One thing I've been trying to figure out is how to inject secrets into my lambda packages so I don't have to have them checked into Git, but also using the right secrets based on an application environment.

Although once they make Lambdas available inside of VPCs I'd be able to do away with a lot of it by a using roles.

author here... I have nothing against CoffeeScript, so that's not really a blocker.

For access keys, so far I stored them as stage variables in the API Gateway config. Claudia adds all stage variables to the env key of the request passed to the Node.js handler. That way, they are instantly available to your function, but never shared with Web clients.

I'm not entirely sure how secure this is, but the use cases I used it for are not highly risky. This is, I imagine, equivalent to storing them in the ENV variables for heroku services. (what I migrated from)

one additional benefit of stage vars is that you can use different values for production, dev and testing, and it all works out of the box.

Reply on news.ycombinator.com