Can Internal Constructs of Pipedream Apps Be Accessed from Node.js Code Steps?

This topic was automatically generated from Slack. You can find the original thread here.

: Is it possible to access the internal constructs of Pipedream apps from Node.js code steps?

For example, if I use the AWS app to communicate with SNS, is it possible to use the SNS client used internally by the app, or do I have to import libraries and instantiate my own client?

No, you cannot access the internal constructs of Pipedream apps from Node.js code steps. Each Pipedream component (trigger or action) is isolated and encapsulates its logic. When you’re writing Node.js code steps within a Pipedream workflow, you’ll need to import libraries and instantiate your own client. For AWS services like SNS, you would typically import the AWS SDK for Node.js (aws-sdk) and configure it with your AWS credentials to interact with SNS. Pipedream does facilitate the process of using AWS services by allowing you to link your AWS account and use the credentials securely in your code steps. Here’s an example of how you might set up an SNS client in a Pipedream Node.js code step: import AWS from 'aws-sdk'; export default defineComponent({ props: { aws: { type: "app", app: "aws", }, }, async run({ steps, $ }) { const sns = new AWS.SNS({ accessKeyId: this.aws.$auth.accessKeyId, secretAccessKey: this.aws.$auth.secretAccessKey, region: 'us-east-1', // specify your AWS region }); // Now you can use the sns client to interact with AWS SNS // For example, to publish a message: const params = { Message: 'Your message', TopicArn: 'arn:aws:sns:us-east-1:123456789012:YourTopic' }; const response = await sns.publish(params).promise(); return response; }, }); Remember to replace 'Your message' and 'arn:aws:sns:us-east-1:123456789012:YourTopic' with your actual message and SNS topic ARN. Also, ensure that you’ve linked your AWS account in Pipedream and have the necessary permissions set up in AWS IAM for the actions you want to perform.

Here’s an example in the common-sns module.

Would there be any way for me to call the snsListTopics() method, or retrieve the client directly from the app?

: Does this make any sense in the context of how Pipedream apps are implemented, or am I better to follow Pi’s advice and instantiate my own client?

Like, instead of using this.aws.$auth to instantiate my own client from the SDK, it would be cool if I could just access this.aws.SNS(), for example.

In the AWS case, if we want to access the client directly, we normally import the client lib from AWS and pass the creds from this.aws.$auth in the constructor:

import AWS from 'aws-sdk'

export default defineComponent({
  props: {
    aws: {
      type: "app",
      app: "aws",
    }
  },
  async run({ steps, $ }) {
    const { accessKeyId, secretAccessKey } = this.aws.$auth

    const route53 = new AWS.Route53({
      accessKeyId,
      secretAccessKey,
      region: 'us-east-1',
    })
  }
})

In general, you can use any of the methods in the app file by importing the app package

import aws from "@pipedream/aws"

export default defineComponent({
  props: {
    aws,
  },
  async run({ steps, $ }) {
    return this.aws.method()
  },
})

But methods in common files like the one you linked to aren’t exported in that package. So we generally try to put most methods in the app file to expose them in the package like this.

Does that help?

Ok cool, thank you! :pray:

for sure, let me know if you have any suggestions for improving this interface. We definitely want the code in these integrations to be accessible via SDK like this

I basically just thought that since the app already had the libraries, I might be able to use them instead of importing them again.

But no biggie, it’s just a few lines of code!

Although maybe the way things are serialized, this.aws may not have access to any of the code.

Most of the app files do expose the client (since we return it for use in other methods) but it’s not done in a consistent way across apps, and many apps use the HTTP API for an app. In the AWS case it’s a little more complex since we don’t expose every client for every service, the getAWSClient method accepts an abstract client (like EC2Client, Route53Client, etc.)

Although maybe the way things are serialized, this.aws may not have access to any of the code.
methods and props from the app file should be exposed in the runtime if the app package is imported and then passed as a prop. Are you seeing specific code fail?

Nah, it’s just wasn’t clear exactly which methods were available.

got it. I think ideally we’d produce JSDocs or something from the repo that clearly exposes only available methods / data!