Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installing multiple stages results in multiple APIs #17

Open
paulbutcher opened this issue Jun 24, 2017 · 6 comments
Open

Installing multiple stages results in multiple APIs #17

paulbutcher opened this issue Jun 24, 2017 · 6 comments

Comments

@paulbutcher
Copy link
Contributor

I'm not sure whether this is me misunderstanding things (it may well be), but I was expecting that if I had production and test stages defined in my project.clj, this would create a single API with two different stages. But what I see instead are two different APIs (with the same name). Am I misunderstanding?

To make this concrete, here is the relevant section of my project.clj:

  :lambda {"test" [{:api-gateway {:name "RotaApi"}
                    :handler "rota-api.core.MyLambdaFn"
                    :memory-size 512
                    :timeout 60
                    :function-name "rota-api-test"}]
           "production" [{:api-gateway {:name "RotaApi"}
                          :handler "rota-api.core.MyLambdaFn"
                          :memory-size 512
                          :timeout 60
                          :function-name "rota-api"}]}

Running lein lambda install test gives me:

Setting up API Gateway with api name RotaApi
Creating role api-gateway-role-saug2l89q6 with policy api-gateway-role-policy-saug2l89q6 and statements {:Version 2012-10-17, :Statement [{:Effect Allow, :Action [lambda:InvokeFunction], :Resource [arn:aws:lambda:eu-west-1:221985399864:function:rota-api-test]}]}
Creating integration with role-arn arn:aws:iam::221985399864:role/api-gateway-role-saug2l89q6
Deployed to https://saug2l89q6.execute-api.eu-west-1.amazonaws.com/test

And then lein lambda install production gives me:

Setting up API Gateway with api name RotaApi
Creating role api-gateway-role-6od4rpb94g with policy api-gateway-role-policy-6od4rpb94g and statements {:Version 2012-10-17, :Statement [{:Effect Allow, :Action [lambda:InvokeFunction], :Resource [arn:aws:lambda:eu-west-1:221985399864:function:rota-api]}]}
Creating integration with role-arn arn:aws:iam::221985399864:role/api-gateway-role-6od4rpb94g
Deployed to https://6od4rpb94g.execute-api.eu-west-1.amazonaws.com/production

Sure enough, when I look in the API Gateway web console, I can see that I have two APIs, both called "RotaApi".

Is this intended?

@mhjort
Copy link
Owner

mhjort commented Jul 3, 2017

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
Copy link
Owner

mhjort commented Jul 3, 2017

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

@paulbutcher
Copy link
Contributor Author

OK, got you. Thanks for the explanation.

@paulbutcher
Copy link
Contributor Author

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
Copy link
Owner

mhjort commented Oct 16, 2017

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
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants