I am trying to create rabbit my using following construct.

const rabbitMQ = new CfnBroker(this, "name', {...});

I want to get connection string out of created rabbitMQ. So I used following code.

environment {
  RABBIT: rabbitMQ.attrAmqpEndpoints[0]
}

Even thought

attrAmpqEndpoints

is documented as

string[]

sst run stat

was throwing error saying I can access array using index directly and I can access it using Fn.select(index, list). So I changed code to

import { Fn } from '@aws-cdk/core';
...
environment {
  RABBIT: Fn.select(0, rabbitMQ.attrAmqpEndpoints)
}

Above code worked, but, I don't understand why there is need to use

Fn

for accessing array element at index. While at typescript should be able to use

list[0]

right?

Morning Pavan, Fn.select is an intrinsic function. These functions need to be used, when properties are not available until runtime. This is because the array of endpoints only becomes available once cloudformation begins to evaluate your stack, inside of AWS. The typescript is evaluated locally on your machine, and at that time, the array of endpoints doesn't exist yet. So, Fn.select tells cloudformation to look for an element in the array, during deployment (once it's available). Hope that makes sense, let me know 👍

That makes sense. But, while creating queue I didn't had to use Fn function like the example below.

this.addOutputs({
  queUrl: aQueue.sqsQueue.queueUrl,
  rabitEndpoint: Fn.select(0, rabbitMQ.attrAmqpEndpoints),
});

I assume even the queue URL is not available until runtime, but it could used directly like

aQueue.sqsQueue.queueUrl

but rabbitMQ array needs

Fn

. I am puzzled with this disparity.

Good question. Amazon sqs queue URLs are deterministic. Composed as: https://sqs.{region}.amazonaws.com/{accountID}/{queueName} So, its fair to say it is probably know ahead of time, but it might use a ref to the string under the hood

Hey @Simon Reilly, thanks for pointing out that the endpoint is resolved at deploy time.. didn’t notice that at first 👀

Thanks you @Simon Reilly and @Frank for explaining.