Installing multiple stages results in multiple APIs about clj-lambda-utils

[mhjort]

Unfortunately I have not (yet) documented the design decisions that this tool is based on. They are based on the experience we had with running AWS Lambda based microservice architecture. We started using Lambda service when it was still in its infancy (there were no versioning, aliases and definitely no API Gateway). So some things here might not make that much sense anymore...

That said, the way the tool works is that every environment specified in configuration is totally separate instance of AWS Lambda (and API GW too). So if you have defined test and production two separate Lambda functions will be created (instead of aliases to certain versions). I chose to use same kind of design in API Gateway too. It will always create separate APIs (instead of separate stages).

[mhjort]

I updated example in README.md to have unique api name in test and production config.

[paulbutcher]

OK, got you. Thanks for the explanation.

[paulbutcher]

FYI, I've subsequently created a Leiningen plugin of my own, which handles stages in the way that I outlined above:

https://github.com/paulbutcher/lein-lambda

Not that I'm suggesting that either approach is "right" or "wrong", you understand - just different.

I've included a link to this repository in the readme, as the inspiration.

[mhjort]

Thanks for the info. The way you handle the stages definitely makes sense and is nowadays more official way for handling the stages. I will still think if that could be used in this plugin too. However, I don't want to break the backwards compatibility. So it needs some thinking...

[paulbutcher]

NP - different approaches are all valid ;-)

Might be nice if we could cross-link to each other so that people who are evaluating which to use know about the options?