Sharing my experience working on a similar project

[daniel-nagy]

Hey!

I came across this project today and just wanted to share that I started a very similar project not too long ago called Transporter. Maybe you will find what I had done interesting!

A gap I see with your library is the lack of support for subscriptions. While working on Transporter, I found that observables were a natural fit for implementing subscriptions, because you can just return an Observable instead of a Promise from an RPC.

One thing I realized while working on Transporter is that if you are passing stubs for functions/objects between the client and server, then that is not partition tolerant. If the server were to say restart, it would not be possible to recover from that state. I'm curious what your thoughts are on that?

Best!
Dan

[econsta]

Hey! I was about to make a similar post, I also published a library about a year ago remote-controller, and I noticed there were a couple of things that they might be able to incorporate.

Namely I got cyclical objects serializing, and I made a first go of garbage collection using a FinalizationRegistry. I'm a big fan of the concept, and I was surprised I hadn't seen very many other libraries trying to implement it. I'm really curious to get some discussion on the best way to implement security in such a system, as I really ignored all security concerns for the sake of convenience when I did my own library, but using it for RPC on a web server is really cool.

[kentonv]

A gap I see with your library is the lack of support for subscriptions.

You can implement subscriptions by passing a callback function.

interface Observable<T> {
  get(): Promise<T>;
  subscribe(callback: T => Promise<void>): Promise<void>;
}

// Use like...
rpcStub.subscribe(value => {
  // handle update
});

There's no need for a built-in notion of subscriptions or observables since you can easily implement these at the application level, just like you would in JavaScript normally.

One thing I realized while working on Transporter is that if you are passing stubs for functions/objects between the client and server, then that is not partition tolerant. If the server were to say restart, it would not be possible to recover from that state. I'm curious what your thoughts are on that?

In Cap'n Web, any object references passed over RPC have their lifetime limited to that of the connection. In the server restarts, the connection is obviously lost in the meantime.

Clients will need to have logic to respond to disconnects by reconnecting and then re-establishing any state. For example, if you had a subscription running, you'll have to reconnect and resubscribe. Depending on the application, you may wan to design your subscription interface so that the client can identify the last update they received, so that the server can continue from that point.

I realize this sounds complicated, but in practice I find it's not really that hard. When I have an app written in React, I pass the root RPC stub as one of the params to my top-level component, and it fetches nested stubs to pass to nested components as needed, some components may fetch data and register subscriptions, etc. When the connection is lost and then restored, the new stub is passed into the top level, all the components re-run their logic to get specific stubs, subscribe to things, etc., and rerender themselves, and it all just works.