Just briefly based on our early attempts (i.e. I haven’t tried again for a few months), the Forge runtime has significant deviations from and limitations compared to Node.js due to its sandboxing approach. In particular, various built-in modules are not supported, which includes XMLHttpRequest, or only partially implemented like the crypto module.
This makes it difficult to adopt more complex third-party libraries that use such features under the hood, and the AWS SDK for JavaScript is one of those, with v2 looking outright impossible, and v3 still looking difficult and likely requiring a patched version or unsupported polyfilling.
- Notably the Forge runtime presents itself as a hybrid between a browser and a Node.js environment, which makes this even more difficult due to the AWS SDK for JavaScript forking its behavior and implementation on that very boundary (e.g. for authentication).
After hitting these walls, we quickly backed out and decided to only use AWS features behind our own APIs for the time being (i.e. API Gateway for REST or AppSync for GraphQL). And this has just gotten more flexible thanks to the new Forge external authentication, which also supports Cognito User Pools.
PS: While I’d ultimately love to see Atlassian leveraging the fact that Forge is build atop AWS by surfacing resp. native integrations (with IAM and EventBridge being the most obvious candidates), their decisions and focus so far seemed to indicate that they do not want go that route currently, so we concluded it wouldn’t make sense to engage regarding those comparatively advanced and platform dependent architectural patterns.