hm, there's definitely some resources that would b...
# azure
h
hm, there's definitely some resources that would benefit from a builder pattern
I've discussed this before with regards to the tailscale ACL document, but I think the Azure Application Gateway could also benefit from this
in python, like:
Copy code
with ApplicationGateway("appgate") as ap:
    listener = ap.HttpListener("listen-80", ...)
    pool = ap.BackendAddressPool("pool", ...)
    ap.RequestRoutingRule('rule-80', http_listener=listener, backend_address_pool=pool)
would make it easier to construct big complex objects with the fluidity we like of Pulumi
especially since both Tailscale ACLs and Azure Application Gateways are highly self-referential, with sub-resources referring to other sub-resources all over the place
c
Checkout
pulumi-awsx
. It's probably the largest example out there of such a pattern. I have a similar example as well, to what you are suggesting. It was for running Folding@Home on Spot VMs on AWS and Azure: https://github.com/cloudy-sky-software/FoldingInTheCloud However, the problem you'd find with such a pattern depending on how many people/teams that use such heavily abstracted components is that changes are harder to make since you probably don't want resource replacements to happen when you make changes. So my suggestion would be to not abstract away too much right from the start. This is one area where I think the AWS CDK team had some nice ideas with their L1, L2 etc. constructs.
h
oh yeah, i'm not abstracting too much at this level
mostly shuffling API into a more enabling form
i just did a wrapper on Application Gateway to test the black magicks I just wrote, and honestly i could have skipped making the wrapper a Component Resource