"This is not a joke provider. Or, it kind of is a joke, but even though it's a joke it will still order you a pizza. You are going to get a pizza. You should be careful with this provider, if you don't want a pizza."
I laughed...
Author here. I got nerdsniped at 2AM a few years back, never expected to see this on HN!
My problem with this approach is that I feel like it's the wrong tool for the job. Am I declaring the state of my pizza? Ordering pizza is inherently an imperative task, and unless we are willing to track the lifecycle of the delivery or the pizza itself I feel like we need to explore alternative solutions. Can any solutions engineers weigh in?
Reminds of "pizza party" CLI back in the day: https://entertainment.slashdot.org/story/04/05/07/138238/piz...
Good fun ordering pizza from your favorite tools!
Would be much more usable if it could be billed to AWS. Then I'd wire it up so my employer would be paying for a pizza with every new deployment...
Today I learned that dominos has a public API for ordering pizza? Or is this some reverse engineered shenanigans? I'm not a Domino's fan, but I need to find this pizzapi
I don't use Terraform/OpenTofu anymore. Thankfully you can enjoy this in Pulumi with their new TF provider support: https://www.pulumi.com/blog/any-terraform-provider
“but use caution, since this is going to charge you money”
terraform apply ALWAYS charges you money!! Use caution because this action will put more on your plate not theoretically but *physically
Seems a bit convoluted.
Compare for example, event sourcing. In that case, you keep a log of all actions taken, and determine the current state by replacing that log.
Here, you have an action that you want to take (order a pizza). But you can't just do that directly, because it's too simple. So instead you tell yourself "I currently have 0 pizzas" (the initial empty state file) and "I want to have one pizza" (your configuration), and you ask it "how do I get there from here".
And then after that is where the real trouble starts. You eat your pizza. You now have resource drift. If you try to correct that drift (does this provider even implement that?), terraform will think it needs to order you another pizza, because it still thinks you want to have one pizza. If you don't fix the drift, then next time you want a pizza you'll have to tell it that actually you want two pizzas. Because what you actually want is an action, but you have to work backwards from the current state (or rather, what terraform thinks the current state is) and what state to tell it you want in order to make it calculate they action.
All of which is more or less the opposite of event sourcing. Instead of wanting a state and having to apply a sequence of events to get that state, you want an event and have to calculate a sequence of state diffs that will produce that event.