Add basic failover functionality

[gtsonevv]

Pre-flight checklist

• [x] I have read the Contributing Guidelines on pull requests.
• [x] Commit messages follow the conventional commits spec
• [x] If this is a code change: I have written unit tests.
• [x] If this changes code in a published package: I have run pnpm changeset to create a changeset JSON document appropriate for this change.
• [x] If this is a new API or substantial change: the PR has an accompanying issue (closes #733) and the maintainers have approved on my working plan.

Motivation

Added support for multiple API Keys (since we can have multiple RPC Servers) Added basic failover functionality With this design of failover, we will change (rotate) our server when needed and stick to this new server for our next calls. It will help to avoid long responses when first (or more) servers are down.

For now, server rotation is happening only on Timeout error.

Also, check this comment: https://github.com/near/near-api-js/issues/733#issuecomment-998869162

Test Plan

Added unit tests.

Related issues/PRs

https://github.com/near/near-api-js/issues/733 https://github.com/near/near-api-js/pull/760

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 65c6899beaee77c3f430769b0e7ff9606057aad1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@near-js/cookbook	Minor
@near-js/providers	Minor
@near-js/wallet-account	Minor
@near-js/accounts	Patch
near-api-js	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[denbite]

The failover mechanism looks exciting to me, I've been tracking it since #760, and it's going to be very useful

However, I wanted to make sure the implementation would cover all use cases, and one of them is what if a user has different connection data for providers

For instance, how can the user provide the following list of RPCs?

[
    {
        "url": "https://rpc.mainnet.near.org",
        "timeout": 2500
    },
    {
        "url": "https://another-rpc.cloud.com",
        "timeout": 2000,
        "headers": {
            "X-Api-Key": "some-string-key"
        }
    },
    {
        "url": "https://one-more-rpc.cloud2.com",
        "headers": {
            "Authorization": "Bearer jwt.token"
        }
    }
]

And it's widespread for each provider to have its own set of headers or other parameters that are required, there's no standard for it

I propose not to extend the JsonRpcProvider class because its primary responsibility is to know how to communicate with RPC and not load-balancing providers, but instead implement the new provider class, let's say FailoverJsonRpcProvider which is going to be the only place that would know about algorithms that are used for failover

export class FailoverJsonRpcProvider extends Provider {
  constructor(
    readonly providers: JsonRpcProvider[],
    // parameters to customize the failover mechanism (retries, total time, etc)
    readonly failoverConfiguration: any
  ) {}


  ...
}

To make it work properly, we would also need to introduce the new field nodeConnections in the configuration

export interface NearConfig {
    ...
    nodeConnections: ConnectionInfo | ConnectionInfo[],
    ...
}

@gtsonevv Please leave your thoughts about this proposal, I'd like to see it considered before merging PR

[vikinatora]

Hey @denbite, thank you for the feedback. On first glance your approach seems reasonable, we'll thoroughly analyze it internally and get back to you.

[frol]

It would be great to have the link to the available RPC providers also easily discoverable for the devs configuring the connection: https://docs.near.org/api/rpc/providers

[denbite]

quite a few people have been asking me recently about the failover mechanism to make their applications more robust, @vikinatora @gtsonevv do you guys have ETA for this feature?

P.S. let me know if you need any help in developing, I'd be happy to take over and deliver this great functionality to active developers as quickly as possible

[vikinatora]

@denbite We can give you an ETA, as we have commited to delivering other functionalities. We'd be happy for you take over and finish this functionality.

[vikinatora]

@gtsonevv, we can close this one.

[gagdiez]

closing as requested by @vikinatora