01/26/2023, 7:38 AM
How should i think about a Pulumi CDK Stack? When I think of a Stack in AWS CDK land, I think of a very heavy thing at the very top-level of my app. It seems like a Pulumi CDK Stack is less impactful and can be thought more of as a Construct that simply bridges between CDK and Pulumi? It really doesn't matter where I use them? As a CDK Construct library author looking to bridge my Construct, should I extend pulumi-cdk.Stack or expect users to do that?


01/26/2023, 2:19 PM
I think it’s a mix. From the perspective of the CDK constructs you are using, it is still a “heavy weight” thing in the sense that it marks the boundary of the CDK compilation. From the perspective of the outer Pulumi code, it’s “just another Pulumi component”. But you typically want to keep that CDK island quite coarse grained because imperative CDK operations only impact things within the CDK island (you can’t create one pulumicdk Stack, then another Pulumi resource, then use an imperative CDK operation to grant permissions to something defined in the pulumicdk Stack - since it will already be deployed at the boundary of the pulumicdk Stack). For CDK library authors, I’d generally encourage not using pulumicdk directly - and just leaving it to your users to be able to consume your constructs from Pulumi via pulumicdk Stack - much like they consume your constructs from CDK using g awscdk Stack.


01/27/2023, 12:12 PM
What about for the Pulumi YAML use-case? In that case, I assume it's better for me to provide an interface that is designed for Pulumi's Inputs and Outputs? One that wraps Stack?
    type: eventual.Service
    serviceName: my-service-name
      TABLE_NAME: !Ref my-table
    type: Table
will be something that wraps my CDK Construct,
, making it available in Pulumi YAML