-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Create js-kubo-rpc-client library #9125
Comments
|
Trying to generate documentation, but I can't seem to do so and can't find instructions at https://github.com/ipfs/js-ipfs It seems like aegir doesn't support generating docs anymore ( Action is running right now: https://github.com/ipfs/js-kubo-rpc-client/actions/runs/2886171949 Updated the action, ipfs/js-kubo-rpc-client@cc2823b, and the site is now visible at https://ipfs.github.io/js-kubo-rpc-client/ |
Created PR to add js-kubo-rpc-client to ipfs/github-mgmt#43 |
Using personal NPM_TOKEN for |
Unified CI should be enabled for js-kubo-rpc-client once protocol/.github#371 and ipfs/github-mgmt#43 are merged |
Updated NPM_TOKEN to use automated token from service account |
Starting work on this now. |
published https://www.npmjs.com/package/js-kubo-rpc-client so I can bring the lib into https://github.com/ipfs/js-ipfsd-ctl |
@lidel @BigLep @aschmahmann, who should I talk to about this? Which stakeholders make the final call for this item? |
Created milestone for tracking each task: https://github.com/ipfs/js-kubo-rpc-client/milestone/1 |
@SgtPooki : We need to make sure that kubo (RPC server) and the js-kupo-rpc-client can interopoerate and that we don't break compatibility between them. We should take whatever tests we had in the past to bootstrap our efforts, but we no longer need to adhere to the "Core API" concept. Basically, I would write tests that invoke the js-kubo-rpc client directly, rather than through legacy "Core API" interfaces. |
So it sounds like Kubo RPC Client should have it's own tests, stripped out from I can make sense of that I think. Thanks |
@SgtPooki and @lidel : question on ipfs/interop when this work is done. Will ipfs/interop assert that a kubo node and a js-ipfs node can continue to interact with each other (e.g., discover each other, transport data)? Will the way that ipfs/interop accomplish this by orchestrating the kubo node using the js-kubo-rpc-client and the js-ipfs node using ipfs-http-client? |
I think for now, we want to do a surgical swap: drop-in replace of |
Seems we are back to the underlying question if both My understanding is:
At the same time we have years of legacy code that assumes both projects expose the same API. Some thoughts on minimizing the painAccounting for the legacy we live with, and being pragmatic (Ideally, we don't want to spend the rest of 2022 on this), I see three ways going forward, would appreciate sanity check from @achingbrain: how feasible (and painful) below are?
|
Thanks for the comments here @lidel. A couple of thoughts.
|
In js-ipfs triage we have come up with a 4th option: The neat trick of the Core API is that it's supported by js-ipfs in-process and both js-ipfs and Kubo over http. We have leveraged this to write the interop suite which is a) massively useful in proving the two implementations can talk to each other and b) about to cause significant type-related pain now that we want to allow the RPC APIs to diverge. The 4th option is to just type the parts of the API that the interop suite uses, store those types in the interop suite and have it use them instead of the types from the Core API. The theory is that both When Kubo breaks the API so badly that the interop suite types are no longer valid, hopefully we'll have the shiny new version of IPFS-on-js that will have it's own interop suite that maybe orchestrates kubo via some sort of API external to it a la |
Excellent. The interop work living in the interop package makes the most sense and should keep us all unblocked for the longest period. Type augmentations should help keep the diverging types manageable. |
* feat: add js-kubo-rpc-client see ipfs/kubo#9125 * chore: update kubo-rpc-client package name * fix: use cross-env to set USE_KUBO_JS * fix: Remove USE_KUBO_JS env var * chore(deps): remove cross-env * docs(readme): update npm install cmds for using kubo-rpc-client * chore: log whether kubo-rpc-client or ipfs-http-client is in use * chore(tests): use kubo-rpc-client for commmunication with go controllers * chore(lint): fix lint failure * fix: addCorrectRpcModule returns the additionalOpts object * docs(readme): correct kubo-rpc-client name Co-authored-by: Alex Potsides <alex@achingbrain.net> * fix: use correct logger namespace convention * fix: move kubo-rpc-client to devDeps * fix: support generics for Controller type * chore(deps): use kubo-rpc-client@1.0.1 * feat!: convert to typescript Converts this module to typescript * chore: fix linting * chore: fix tests * chore: apply suggestions from code review * fix: resolve issues with js-kubo-rpc-client in typescript * fix: use kuboRpcModule for go in factory.spec.ts * fix: broken build from bad merge * chore: address PR comments Co-authored-by: Alex Potsides <alex@achingbrain.net>
FYI I made a "CI test that fails when a new command is added to Kubo and is not supported by |
Note that the latest work to close out the last action item in this issue (ipfs/js-kubo-rpc-client#5) is being handled via pull request ipfs/js-kubo-rpc-client#83. I'll be meeting with @hacdias tomorrow (2022-12-06) to go over some of these tests and confirm next steps and handoff requirements. Note that the original interface tests were testing against ninja-edit: There are technically two last items as seen on the milestone tracking the closing of this issue: https://github.com/ipfs/js-kubo-rpc-client/milestone/1, but the "revert patch-only release changes" is trivial so was not mentioned in the original comment. |
Latest actions required prior to handoff: ipfs/js-kubo-rpc-client#83 (comment) |
Note that ipfs/js-kubo-rpc-client#83 has been merged! |
Thanks @SgtPooki for bringing this to this point. The done criteria are satisfied, thus I think it's reasonable to close this out. I know there are additional tasks to do to further harden js-kubo-rpc-client and those are in ipfs/js-kubo-rpc-client#56 Closing - thanks again! |
With this issue closed, should we point all users of https://github.com/ipfs/js-ipfs/tree/master/packages/ipfs-http-client to this? The NPM page could also use a notice: https://www.npmjs.com/package/ipfs-http-client |
ipfs-http-client is still used to connect to js-ipfs, so not all users, but it could use a message saying to use the kubo rpc client with kubo. |
ETA: 2022-12-16
Current state
Kubo shares RPC client with JS-IPFS:
After renaming GO-IPFS to Kubo, this state of things is arguably a bad user experience:
Desired state
Ideally, we should have one Kubo client at https://github.com/ipfs/js-kubo-rpc-client and
kubo-rpc-client
on NPM.Keeping
go-
prefix is important because we want consistency across languages,and Kubo team will maintain
go-kubo-rpc-client
too.TODO
Below is a broad strokes plan, feel free to adjust if something else makes more sense:
(this way developers are not forced to use https://github.com/ipfs/js-ipfs/tree/master/docs/core-api which is maintained manually and often contains bugs or parameters that are not supported by Kubo)
ipfsHttpModule
andkuboRpcModule
(we will also rename binary package, but that is tracked separately in Rename NPM package to kubo npm-kubo#51)
js-kubo-rpc-client
and run it in the CI ofjs-kubo-rpc-client
repo(we already run
ipfs/interop
tests in Kubo CI, but it is too late, we should do it in the library repo CI too)decide if js-kubo-rpc-client CI should reuse tests against Core APIs interface-ipfs-coreKubo RPC Client should have it's own tests, stripped out from interface-ipfs-core. And we should only bring over the tests that are applicable for kubo's supported RPC calls. Pull out relevant tests from interface-ipfs-core js-kubo-rpc-client#5js-kubo-rpc-client
to Kubo READMEipfs-http-client
and switch tokubo-rpc-client
where Kubo daemon is usedipfs-http-client
(js-ipfs rpc client), and when the kubo oneFollowups
Below are good improvements, but since we didn't have them with ipfs-http-client, we're not requiring them here.
kubo-rpc-client
yetcc @2color @BigLep @achingbrain @SgtPooki
The text was updated successfully, but these errors were encountered: