Sharing Iroh node between applications?

[bn-c]

Please excuse my silliness for asking this question, but I am currently used to the IPFS way of thinking. There is an issue in IPFS where if you were to spin up a separate daemon (RPC endpoint + Blob Repository + Swarm Networking) for every single application, things get out of hand.

Thus, there are light-weight RPC wrapper libraries. Where on a machine you would have a central daemon, usually Kubo, running and exposing localhost:5001, and every application on that machine wishes to interact with data within IPFS would only need to load the wrapper and points to the endpoint.

Reading through Iroh's examples, I am seeing this:

 let node = iroh::node::Builder::default().enable_docs().persist(data_root)
        .await?
        .spawn()
        .await?;

Which, I assume, creates a new Iroh node, with the blob repo located at data_root. Would this be a overhead concern?

[matheus23]

Not a silly question at all :)

If you've played with the iroh CLI at all, you'll see a bunch of things that will feel familiar to you: There's a iroh start command that is roughly equivalent to ipfs daemon, and any commands like iroh blobs add or iroh blobs get require that you have iroh start running concurrently (unless you run iroh blobs add --start which will do an iroh start internally).

The CLI does this via a QUIC-based RPC library we built (quic-rpc). In fact, in the code example you've posted above, when you access the node.client(), that returns you an RPC connection to the node (fun fact: In the same process, this connection will be optimized and skip all serialization!).

Spawning a node and getting a node.client() isn't the only way to obtain an RPC connection to a node, another way is to use e.g. Iroh::connect_path to connect to an iroh node in another process, or Iroh::connect_addr to connect remotely (if the node is configured to allow that).

Would this be a overhead concern?

It really depends on your setup. It should be said that running something like iroh start is vastly less resource intensive than running ipfs daemon. The biggest reason for this is that iroh doesn't participate in a DHT by default and thus has to keep way fewer connections alive at once.