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

CloudFormation code deduplication #6

Open
alexcasalboni opened this issue Sep 11, 2017 · 3 comments
Open

CloudFormation code deduplication #6

alexcasalboni opened this issue Sep 11, 2017 · 3 comments

Comments

@alexcasalboni
Copy link
Collaborator

As mentioned in #2, a considerable part of the CloudFormation-related code could be better modularized/centralized. Such a refactor should also allow for framework-specific specialization.

@danilop
Copy link
Owner

danilop commented Sep 11, 2017

Good point, if you have an idea of how/what to refactor, happy to help!

@rts-rob
Copy link
Contributor

rts-rob commented Sep 11, 2017

I agree with DRY, but after spending time looking into this issue (and a first stab at the Terraform engine's basic functionality) I'm not convinced that's what we have here. Refactoring this way puts the resource first instead of the engine first. I don't think this will be helpful, especially if we're going to support Terraform as a first class engine.

Put another way, the engines are like languages. A Terraform DynamoDB resource looks and feels much more like a Terraform Lambda resource than it does a SAM or Serverless DynamoDB resource. I think we gain from reading through the engine file in one specific engine's mindset/language, even if that means repetition of close (but not identical) code.

Simple Example

I built up the following simple application, with a single DynamoDB table that invokes a single Lambda function.

{
  "nodes":[
    {"id":"someFunction","x":-110.5,"y":-429.5,"label":"Lambda Function\nsomeFunction","model":{"type":"fn","description":""},"group":"fn","shadow":false},
    {"id":"someTable","x":-361.5,"y":-465.5,"label":"DynamoDB Table\nsomeTable","model":{"type":"table","description":""},"group":"table","shadow":false}
  ],
  "edges":[
    {"from":"someTable","to":"someFunction","label":"stream","color":"Blue","id":"d7541d98-ea74-460b-8c2a-d516bb716f19"}
  ]
}

The generated SAM template seems fairly close to the generated Serverless template, but when we look at the corresponding Terraform file, we're on to something completely different.

WARNING - Rampant Speculation Follows

It seems to me that SAM and Serverless are superficially close but diverging. Serverless started off only supporting AWS, so this is natural, but as the framework continues to branch out it's going to develop its own "dialect," if you will. Terraform came from a completely different place and may as well be a completely different language. I don't see it converging with SAM or Serverless any time soon.

@alexcasalboni
Copy link
Collaborator Author

@rts-rob That's a good point too.

I liked the idea of being able to extend and specialize an engine (if not resources) rather than re-defining 90% of it just because of small differences. But this is probably a special case between SAM and Serverless, and this issue can stay in the backlog until the project's direction and scope are better defined.

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

No branches or pull requests

3 participants