Google Apps Script runtime support for @anthropic-ai/bedrock-sdk

[dandv]

I work with @zack-anthropic on the Claude for Sheets™ extension. CfSh uses the Google Apps Script runtime, which doesn't support library loading, but can make HTTP(S) calls.

The Anthropic API is directly callable through HTTPS, but the Bedrock library goes through a rather complex process of signing the request and adding headers before submitting it to a URL different from the https://bedrock-runtime.{region_name}.amazonaws.com endpoint.

Having GAS support would make using the latest version of the library straightforward, and would avoid a cumbersome and partially manual build process. An example of popular library with GAS support is lodashgs.

The required support would be limited to text prompts and responses without streaming.

[rattrayalex]

Do you know of a way for us to test whether it works in gs without opening a web browser? (e.g., for automated tests & CI).

What doesn't work about the current library today?

[dandv]

clasp supports runing functions remotely.

@anthropic-ai/bedrock-sdk works fine locally. The problem is that Google Apps Script doesn't support loading external JS, or NPM packages.

The lodash folks created a JS build, then likely shared the library. The ID of the script mentioned at that developer.google.com page is probably the 1SQ0PlSM... project key at https://github.com/oshliaer/lodashgs.

[rattrayalex]

Ah. I don't think we'd want to be responsible for bundling and publishing a separate package for each build. Is this something you can do?

[dandv]

I gave it a shot and documented my work and the issue I ran into: an async iterator that Google Apps Script doesn't support, and esbuild can't transpile.

While it would be great is esbuild added support for async iterators, would it be possible in the meantime to either refactor that code, or create a minimalistic Anthropic Bedrock module for GAS that doesn't use streams (or assert), and just signs and makes the HTTPS request to the Messages API?

[rattrayalex]

I'm very sorry, unfortunately we're only able to support environments with async iterator support. You might be best off forking the repo.