Why use "branded" providers (Alchemy, Infura) instead of generic ones? What are the pros?

[DefiCake]

Why use AlchemyProvider or InfuraProvider instead of the generic JsonRpcProvider or WebSocketProvider? Do they use different APIs underneath?

[ricmoo]

Some providers do provide additional APIs (although for the most part this has been under-utilized by them in Ethers), but keep in mind all these Providers just sub-class JsonRpcProvider (and WebSocketProvider), but simply use their specific logic to convert the network to a URL, custom parameters, etc. and pass it to super.

For example, all these providers are "static providers", so they are automatically configured that way (so there is never a need to call a remote eth_chainId).

It also helps the getDefaultProvider function which takes in a network name, as it can then create all the backends without having to have knowledge of how each service converts its network name to a URL. But this could be replaced with a getJsonRpcUrl(network, service) in the future.

Originally it also allowed per-service configuration, for example INFURA supported gzip-encoded responses (which drastically reduced bandwidth) which other services didn't, so that could be baked in to the "branded" provider.

There has definitely been some benefit over the years, as each provider has occasionally had slight incompatibilities which was able to be addressed in the custom logic of a given provider until it was fixed.

This was also established before JSON-RPC providers were a "thing"; originally they only provider in Ethers was the EtherscanProvider (which uses custom API endpoints) and the JsonRpcProvider which was only useful for connecting to your own Geth instance. As time went on, Infura came along. And so on. Just some random history. The first version of Ethers came out in 2016. :)

But in the long run, it would be nice if this design could be retired as most providers behave in mostly compatible ways now. :)