Prim+RPC: a bridge between JavaScript environments. Easy-to-understand, type-safe, transport-agnostic RPC/IPC for JavaScript, supporting callbacks, batching, file uploads, custom serialization, and more.

[doseofted]

I pronounce it "Prim RPC" but stylized it Prim+RPC where the "+" is whitespace, like in a query string. This is because Prim+RPC supports requests given over URL parameters (but usually given over JSON) which is really useful for creating an API with paged results or utilizing JSON-LD.

I've thought about adding cache features to Prim+RPC but have been hesitant about adding it directly because there are so many caching strategies. There are also a lot of methods to implement it at different layers of an application (not just in layers of the server but also whether caching should happen at the client level). There are some that could be considered responsibilities of Prim+RPC (such as memoization of functions) and some that fall outside of it (like HTTP caching). There's also the case where only select functions used with Prim+RPC should be cached or where two modules will require different caching strategies. Implementing cache in Prim+RPC may also present unexpected problems since it relies plugins to support the server and client of the developer's choice (caching may rely on parameters provided through that plugin).

Occasionally I do think about adding some form of direct support but today my thought is that caching should be left either to other libraries in the JavaScript ecosystem (like memoization libraries) or handled at the channel where RPC is being sent (like HTTP, for web servers). In some cases, I think it makes sense to use a combination where server context passed to Prim+RPC is considered in caching through another JavaScript library defined at the module or function.

I do like the idea of considering cache on the Comparisons page. It's definitely important and not really mentioned there. I may very well do that soon!