search

pitch-foundation / hourglass-sdk

Hourglass SDK
https://pitch-foundation.github.io/hourglass-sdk/
0 stars 1 forks source link

Figure out a way to support viem as library for Chain interaction #6

Closed bam4564 closed 5 months ago

bam4564 commented 6 months ago

For both the ION protocol use case and for use within the Hourglass backend, we use the viem library. I want to make sure that this SDK is easy to plugin to a frontend or backend application that leverages viem in addition to ethers v5. It's nice that we use ethers v5 on the frontend and viem on the backend so we have practical apps that we can test both versions of this library with.

Not sure how we can do this off the top of my head but this is something that we'll need to solve. Think we might need to have multiple sub-packages within this repo with different sets of dependencies (ethers v5 in one and viem in the other) with a shared set of logic that is agnostic to the underlying chain interaction library used under the hood.

The core websockets logic doesn't actually require chain interactions so we might want to separate our the event emitters for the data and rfq namespaces with the auxillary utility logic we need to perform the websockets interaction. We can hop on a call at some point to brainstorm more about solutions here.

alex-hourglass commented 6 months ago

Added viem adapters to transform the viem Client into JsonRpcSigner and JsonRpcProvider

These are already used in the hourglass-headless repo as we're using viem there and I didn't encounter any issue. Let me know what you think about this solution.

bam4564 commented 6 months ago

I think this is a good solution for now, but I eventually want to move to something that ensures that only one version of the library (ethers v5 OR viem) needs to be installed for the package to work.

For example, if when we integrate with ION, and they want to leverage the SDK, they'll have to install ethers just for this downstream dependency. I'd rather we find an approach that splits out any chain specific logic to a separate package that only requires one of those two libraries. They might be resistant to using the SDK if they have to install all of ethers which has a notoriously large bundle.

A good example of this is typechain which requires a target to be installed so typechain the library knows the format for generating code. Not sure if their way of doing typescript packaging just giving an example of a third party library that has a dependency on one of a set of multiple possible libraries.