home

ArticCon 2022 (continued)

Rather than plumb in all of those changes, remapping them explicitly when we declare a resource like this

new ComputeSubnetwork(this, subnet, {
  name: subnet,
  cidrBlock: i[vpc][subnet].config..cidr
  gatewayAddress: i[vpc][subnet].config.gateway
  // there are a total of 23 potential arguments for this resource alone
})

It would be easier to transform our data into datastructure that’s easier to program with so we can just hand off the configuration as a single variable

new ComputeSubnetwork(this, subnet, i[vpc][subnet].config)

And any extra arguments can still be added by destructuring or spreading depending on your language of choice

new ComputeSubnetwork(this, subnet, {
  ...i[vpc][subnet].config,
  anyExtraArgs: canStillBeAdded
})

Previous Next
Back to talks
1. Front Page
2. intro: before we begin
3. intro: my background
4. cloud config
5. cloud config: WebUI
6. cloud config: CLI
7. cloud config: IaC
8. cloud config: cognitive load
9. terraform: at a glance
10. terraform: HCL and usage
11. terraform: modules
12. So why not just use modules?
13. cdktf: enter language bindings
14. cdktf: compatible with terraform
15. schema: configuration
16. schema: networks
17. schema: firewalls
18. schema: peers
19. schema: enforcement
20. etl: for many reasons
21. etl: current and desired state
22. arguments: sidebar
23. etl: implementation
24. etl: additional types
25. etl: facilitating abstractions
26. abstraction: implementation details
27. abstraction: example
28. abstraction: but still concrete
29. types: but why
30. demo: full