https://pulumi.com logo
Powered by
Title
t

tall-librarian-49374

07/13/2018, 1:00 PM
Can I not send a message to 
aws.sqs.Queue
from JS?
s

stocky-spoon-28903

07/13/2018, 4:38 PM
Can you use the regular SDK for this?
👍 1
t

tall-librarian-49374

07/13/2018, 6:48 PM
I guess I can... would be handy to do it directly from pulumi though (from cloud API in my case)
OK, it works. A bit verbose but good enough for now.
s

stocky-spoon-28903

07/13/2018, 8:02 PM
Maybe a simple API would be a good addition to the 
pulumi-aws
package?
b

big-piano-35669

07/14/2018, 4:02 PM
We definitely want to enable these high level API wrappers over time. This is effectively the intersection of Pulumi's resource APIs and the AWSK SDK itself. I think we're still on the fence about how and where to add this, which is probably why it hasn't happened yet. There are two top-level options: 1) Exactly as @stocky-spoon-28903 suggests, by using overlays in the 
pulumi-aws
package itself 2) In a higher level package, similar to https://github.com/pulumi/pulumi-aws-serverless (1) is very appealing, because it'll "just work" and discoverability will be improved, except that we tend to like to keep this layer unopinionated. (2) at least lets us call this what it is -- an optional opinionated layer atop the raw primitive resources -- however, that gets a big -1 in the "it just works" and easy-to-discover category. I also think @white-balloon-205 is worried about our ability to keep up with covering such a broad surface area (in the limit, the entire AWS SDK), however I suspect we can deliver most of the value by doing the Top 20 resource types (SQS queues, Dynamo Tables, etc).
I'm not sure if we have a work item already for this -- @white-balloon-205, @lemon-spoon-91807, do we have anything for the broad issue of adding runtime APIs for these abstractions? Or has it been sufficiently just a vague idea that we haven't filed one yet?
l

lemon-spoon-91807

07/14/2018, 4:04 PM
i believe the latter
especially not at the pulumi-aws-serverless
it would make the most sense a the pulumi-cloud level, where the goal is to provide a more pleasant overall abstraction over these sorts of resources
b

big-piano-35669

07/14/2018, 4:05 PM
I will file in pulumi-aws for now, since it's not obvious where we'd add these. I do think as simple overlays they would work fine and, since it's the AWS SDK itself, it's less "opinionated" than many other layers like the cloud framework.
l

lemon-spoon-91807

07/14/2018, 4:06 PM
our examples to try to demonstrate this pattern. so, 'pulumi' for resource creation/organization, and aws-adk for interaction with broad surface area of AWS.
b

big-piano-35669

07/14/2018, 4:06 PM
Right, it's just so much nicer if the actual 
sqs.Queue
type "just works" out of the box.
l

lemon-spoon-91807

07/14/2018, 4:07 PM
yes. i can definitely see the appeal
my concerns (not having looked too deeply into aws-sdk) would be:
1. how broad is this API. i.e. would basically every resource type get a large set of additional abstractions to support
2. how maintainable would that be. would we always have to be keeping these up to date with the aws sdk on top of everything else.
on the other hand, this is just code, and just JS. so part of me really likes the idea of having another library you can import. and it would just augment these libraries with the desired changes
this is not an uncommon pattern in the JS world.
i'll discuss this a bit with @white-balloon-205 this week. it actually ties into our design thoughts on 'serverless'. i.e. why have 
serverless.sqs.onQueueEvent(queue, () => ...)
if you could just have the serverless package augment Queue itself so you could write: 
queue.onEvent(() => ...)
b

big-piano-35669

07/14/2018, 4:31 PM
I definitely agree with the concerns and I'll admit, until just recently, I had always assumed we'd do this as a separate library. At this point I think it's a low risk add and that stuff like this should "just work", especially as it highlights the unique "it's just code" aspects of Pulumi. I filed https://github.com/pulumi/pulumi-aws/issues/271 -- let's move discussion there so it's not lost to the Slack sands of time 🙂
s

stocky-spoon-28903

07/14/2018, 4:34 PM
I think having a separate library for this is fine. The critical part (as compared to the AWS SDK for example) is that it can be made to work with the existing provider configuration IMO
#generalJoin Slack
Powered by