I don’t view this ratio as a better/worse thing. Config as code it a good practice already, and once you have that, it’s moving complexity, not creating it.https://twitter.com/springrod/status/1002379190174302208 …
Agree 100% the existing examples are garbage. I wish they would take a serverless first approach. Show me a complex system of >10 fns reacting to events from >3 services.
-
-
Off by one error, 10% of your system just broke.
-
I think its possible to make a tool that makes these kinds of mistakes hard and also lets you write JS
-
I think that generally requires solving the halting problem
-
hmm? Not sure I understand 100%. It doesn't need to be perfect. "I'm sorry Dave, I can't do that because it would destroy data" will get you pretty far.
-
When we have to *run* an infra spec to find out what it does, I think we've overcomplicated things
-
Eh, I just disagree. Ideally we can staticly analyze (so maybe vanilla JS is not right. I'm open to that point)
-
My first crack JS idea would be to make any infra variable declarations outside of the top level scope lint errors. I think you could make a runnable JS program that would build an entire infra graph without actually running any code.
-
Eh I should prob not twitter speculate on this and just try and build a POC. I'm almost surely missing something.
End of conversation
New conversation -
-
-
One of the big issues I have with the current setup is your infra dependency graph is prob already split between code and config. Example: dynamo streams -> lambda -> SNS chain. That second edge is expressed in the lambda code. The first one is in CF.
-
A tool that unifies application and infra code could understand that. I don't think it exists, but it feels possible.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.