Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(bedrock-sdk): allow for custom provider chain resolvers #474

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

linus-amg
Copy link
Contributor

@linus-amg linus-amg commented Jul 23, 2024

to allow also being executed in a non-node environment.

I'm trying to modify the bedrock sdk code so that it's executable in a non-node environment (e.g. vercel's edge runtime), as a first step I swapped the fromNodeProviderChain with a dynamic import and as a second step the client creation now allows for defining a custom provider chain resolver, which should enable the following usage:

import AnthropicBedrock from '@anthropic-ai/bedrock-sdk';

const client = new AnthropicBedrock({
  awsSecretKey: '<insert your own aws secret key>',
  awsAccessKey: '<insert your own aws access key>',
  providerChainResolver: customFunctionWhichReturnsCredentialProvider
});

whenever a providerChainResolver is not defined, the fromNodeProviderChain from @aws-sdk/credential-providers should be used.

this should help fixing issue: #380 + #314 (comment)

I'm looking for a way to automatically test this new implementation, any ideas? I saw that for testing the bedrock sdk there is a script called "test" which executes: bin/check-test-server && yarn jest but bin/check-test-server does not exist in the public repository, are there other ways to test this?

to allow also being executed in a non-node environment
@linus-amg linus-amg requested a review from a team as a code owner July 23, 2024 11:12
@RobertCraigie
Copy link
Collaborator

RobertCraigie commented Jul 29, 2024

Thanks for the PR!

I'm trying to modify the bedrock sdk code so that it's executable in a non-node environment (e.g. vercel's edge runtime), as a first step I swapped the fromNodeProviderChain with a dynamic import

Is this strictly required? e.g. did you run into an error when this import wasn't dynamic?

I'm asking as we want to support both CJS & ESM and I have a suspicion that dynamic import won't work with CJS, we'd need to double check.

edit: the comment you linked does show that a non-dynamic import causes breakage.

I'm looking for a way to automatically test this new implementation, any ideas? I saw that for testing the bedrock sdk there is a script called "test" which executes: bin/check-test-server && yarn jest but bin/check-test-server does not exist in the public repository, are there other ways to test this?

Ah unfortunately we don't automated tests setup for the Bedrock SDK yet, we just rely on smoke tests running the example scripts.

@linus-amg
Copy link
Contributor Author

thank you for checking @RobertCraigie - so what's needed for this PR to move forward is to provide a way to make this work for cjs, correct?

@RobertCraigie
Copy link
Collaborator

so what's needed for this PR to move forward is to provide a way to make this work for cjs, correct?

yes, I think we won't be able to merge this without supporting CJS unfortunately

@RobertCraigie
Copy link
Collaborator

I think we might be able to use export maps like we do in the main SDK package right? then users don't have to know to pass a custom provider chain resolver

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants