Are you considering supporting other protocols

[I-Want-ToBelieve]

This library is eye-catching. awesome!

How high is the call overhead when used on a single machine?

Would it be faster if communication is done through shared memory?

How fast does a client cold start?

[doseofted]

Thank you! I don't have benchmarks yet for Prim+RPC but I would like to test performance and maybe compare it with other libraries. The core of the library is only performing small transformations to/from RPC but additional processing may happen for types that are extracted from JSON likes files/callbacks and may have an effect on performance.

Performance also depends on which plugins are used (these plugins are available today, supporting different protocols and frameworks). There are a few optimizations that could be made to plugins for IPC on a single machine that I'm considering as a part of an internal refactor.

When you say shared memory, are you referring to usage of shared array buffers? With the plugin for Web Workers, you can choose to use structured cloning instead of JSON serialization which allows passing regular array buffers (but those are transferred, not shared from my understanding). I'm not very familiar with using shared array buffers just yet and may need to play around with those to better understand how they may be used with Prim+RPC.

[I-Want-ToBelieve]

Thank you for taking the time to answer.

I've seen the plugin, and I've noticed that you're binding the use case to the web.

Maybe in the future this library could consider using Unix Domain Socket and memory sharing via the plugin for traditional stand-alone inter-process communication without network protocols.

Node's long cold start times don't make much of a difference when it's server-side, but considering that clients that start and shut down frequently and are sensitive to latency, they perform better with a native compiled language similar to Rust.

[doseofted]

The Web Workers plugin works on the web but it's also intended for frameworks like Bun and Deno which support them natively. Another planned plugin for IPC is Node's child processes which may fill that use case. Is there a potential plugin that you have in mind?

The core of the RPC framework is just event emitters and doesn't communicate over a network so a new IPC plugin could be created if it doesn't exist yet. The testing plugins are a good example of showing the event flow of the library.

Concerning cold start times, is this in reference to a serverless environment? While I don't have benchmarks yet, I expect Prim+RPC to have very minimal impact on app startup because it doesn't do much until an RPC is received.

[I-Want-ToBelieve]

I have a use case that requires communication between the node server and the rust client.

I am using zeromq now, you can take a look at this library https://github.com/zeromq/libzmq to see if it can bring you some inspiration.

zeromq has implementations in multiple programming languages, which is a highlight among libraries for cross-process communication.

For prim-rpc, if this is taken into consideration and combined with the existing highlights of prim-rpc, then prim-rpc will become even better.

I don't have many ideas about prim-rpc plugins.

Regarding cold start, serverless is one side, and in my use case it's client side.

I initially used the node version of zeromq in both the server and the client, but the client was opened and closed very frequently, so I couldn't ignore the cold start time of node itself.

In the end I used the rust version of zeromq and rewrote the client in rust.

The publish-subscribe model of zeromq has a latecomer problem, that is, the first message will be lost.

I found this library when searching for alternatives on github, and found that prim-rpc is really unique.

If prim-rpc also considers native communication after satisfying web use cases, I think there will be many people implementing it in other languages, just like zeromq.

[doseofted]

I would love to see implementations of Prim+RPC in other languages but Prim+RPC's design takes advantage of JavaScript-specific features to keep RPC transparent, including JavaScript's metaprogramming abilities and TypeScript's separate structural type system. Other languages do have comparable or alternative features that could allow an implementation to be written but would require a compilation step or less transparent RPC. But with support from a community of developers, it would be interesting to consider.

RPC messages are designed to be simple to make without the library and I hope soon to support typed RPC outside of TypeScript by generating JSON Schema from code documentation. This may act as a useful bridge for those who primarily use JavaScript but sometimes need access from other languages.

Prim+RPC can support communication over many transports including outside of the web use case but part of its simplicity does involve specific JavaScript features which makes an implementation in another language, not impossible, but fairly involved.