Cam Feenstra

I've been thinking of writing something up to answer precisely this question in a bit more depth, I had a feeling it would be asked sooner or later

W/ stackattack I took the approach of implementing components as simple functions that can be easily copy/pasted and extended in your own codebase (w/o needing to recreate anything), and keeping the configuration that can be done on components relatively limited

They also seem to straddle a sort of middle ground where their components try to remove boilerplate but still not be too opinionated, so I've found that putting together real infra stacks still requires a lot of code, and there isn't great documentation for their components

I have used their awsx package in the past, and I don't love some of the design decisions; the biggest thing is they use Pulumi's class-based "component resources", which actually become part of the resource state and thus make it quite hard to migrate away from them without recreating things

Do you have to learn the special key combos to enter the mathy symbols or are those ligatures?

I loved doing proofs in college, been getting enough fomo from how much fun you’ve been seeming to have w/ lean that I’m sort of itching to give it a shot

I wrote about the motivation being Stackattack, the AWS + Pulumi components library I've been working on to address the "cold start problem" that many have when wanting to manage their infra w/ IaC tools

www.camfeenstra.com/posts/infra-...

#IaC #pulumi #aws

On the off chance anyone who sees this likes Pulumi and wants to delete a bunch of code, you should try it out!

The reason I made this is just because setting up infra as code for a full infra stack initially is incredibly tedious and usually takes me a lot of iterations to get right. Once you have it working, it’s pretty magical though

It also means that you can copy/paste and extend these components without needing to migrate or recreate anything

One of the design choices I made was to use functions for components instead of pulumi’s component resources; I really like this approach because it means that the components aren’t represented in Pulumi’s resource graph (except via naming conventions)

GitHub - cfeenstra67/stackattack: Production-ready AWS components for Pulumi Production-ready AWS components for Pulumi. Contribute to cfeenstra67/stackattack development by creating an account on GitHub.

I’ve been working on a library of high-level Pulumi+AWS components, it’s pretty cool if you ask me: github.com/cfeenstra67/...

you stand accused of solutioning, how do you plead

tfjs is pretty sick