search

multiformats / js-multiformats

Multiformats interface (multihash, multicodec, multibase and CID)
Other
232 stars 54 forks source link

Replace CID class with a CID interface #96

Open Gozala opened 3 years ago

Gozala commented 3 years ago

Most of ipfs / libp2p stack depends on CID class which introduces large number of dependencies, it is made worth by the fact that typescript forces all of them to agree on the same exact package to type check.

We should instead introduce CID interface and type our APIs so they take / produce value compatible with that interface. That way they become implementation agnostic allowing us to swap / upgrade implementation without coordinating these changes across the board.

CID Implementation in this library will just become a an implementation of that interface.

rvagg commented 3 years ago

How deep do we go with this, though? Should we also ship BlockCodec and Multihasher interfaces separately? I agree that CID is the most commonly used piece and it makes this library core of all our new work and it'd be nice to reduce that strict dependency, but there's a second layer of pieces which are very common so I'm wondering how far we take this approach?

Gozala commented 3 years ago

How deep do we go with this, though? Should we also ship BlockCodec and Multihasher interfaces separately?

They are interfaces already they just happen to live in the same repo. I think it would make sense to move interfaces into separate repo because:

  1. Interfaces should not be changing nearly as often.
  2. Alternative compatible implementations could be developed without introducing dependency on existing implementation.

That said I do not want to overcomplicate things too much. For this specific issue my plan was to just define CID as an interface similar to Multihasher, BlockEncoder etc... and change CID factory functions to return CID interface as opposed to class.

We can always move things between repos and package names if needed.

there's a second layer of pieces which are very common so I'm wondering how far we take this approach?

Generally speaking I think coding against implementations is a bad practice as it introduces incidental coupling. I find approach of specificity external dependencies through interfaces to work much better as they allow alternative implementations to be used. It also enables case specific optimized version to be introduced and dropped in without added coordination overhead.