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

Replace CID class with a CID interface #96

Open
Tracked by #3725
Gozala opened this issue Jun 24, 2021 · 2 comments
Open
Tracked by #3725

Replace CID class with a CID interface #96

Gozala opened this issue Jun 24, 2021 · 2 comments

Comments

@Gozala
Copy link
Contributor

Gozala commented Jun 24, 2021

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
Copy link
Member

rvagg commented Jun 25, 2021

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
Copy link
Contributor Author

Gozala commented Jun 30, 2021

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.

@Gozala Gozala mentioned this issue Jan 19, 2022
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 a pull request may close this issue.

2 participants