https://pulumi.com logo
#general
Title
# general
a

abundant-computer-36798

12/06/2022, 5:15 AM
It appears the Fargate TS sample code (link) uses deprecated bindings. It uses
awsx.elasticloadbalancingv2.NetworkListener
, but this no longer exists. I think it moved from
awsx
to
aws
at some point, to
aws.elasticloadbalancingv2.Listener
. (Could someone verify / explain what falls under
awsx
vs
aws
?) And then I find out from the docs that now this is deprecated in favor of
aws.lb.Listener
, so I should really be using that? And to further the confusion, I learn that everything under
@pulumi/aws
is known as classic, and if I want to stay modern I should actually be using
@pulumi/aws-native
instead of any of the options above? Incredibly, although
elasticloadbalancingv2
got renamed to
lb
in classic, it's back to being called
elasticloadbalancingv2
in native!
f

fierce-ability-58936

12/06/2022, 10:04 AM
There have been some changes made to the awsx library since that example was created. Long story short, the example should still work 🙂 Longer explanation: As we can see in package.json, it uses version 0.40 of awsx. This version of the package written in TypeScript and can only be used in TypeScript. Later on, it was rewritten as a multi-language package, so that it can be used from any other language supported by Pulumi. As part of the above, the old TypeScript-only resources got moved to this directory: https://github.com/pulumi/pulumi-awsx/tree/master/awsx-classic So everything from the example can be used even with the new version of the package (which is >1.0 now). It didn't move from
awsx
to
aws
, because the
aws
package reflects resources from the corresponding terraform aws provider.
awsx
is a wrapper around that
aws
provider that provides you with some sensible defaults and allows to get started quickly. It's not a separate thing, it just complements the original
aws
provider. Ok, so now the classic / native. The classic
aws
package utilises the terraform provider, with its convenience hacks (like a security group association resource, which is not a real resource). Whenever a new service appears from AWS, or an existing one gets a new feature, it has to go through the aws terraform provider development cycle, to be included later on into the Pulumi's aws provider, which will just update the terraform provider version under the hood. The Pulumi's "native"-type providers are created differently. They're generated from the API specs, and can be quickly regenerated whenever there's a change in the spec. Then are much leaner in a sense and allow to bring new features quickly. Which one to use? Depends on the use case. I'd still have the classic
aws
as the base, and add
aws-native
if there's a feature I need, which doesn't exist in the former yet. Disclaimer: I'm not affiliated with Pulumi org, I'm just a fellow Pulumi user who likes processing information 😄 If I made any wrong statements or assumptions, please correct me!
a

abundant-computer-36798

12/07/2022, 8:05 PM
Thank you! So the elastic load balancer v2 was formerly in awsx because it awsx had some helpers to create sensible defaults, but post version 1.0, the aws package eventually built this in so the awsx load balancer helpers were removed?
f

fierce-ability-58936

12/07/2022, 8:29 PM
(just has a different name)