Provide `DynamicProxy` alternative

[AArnott]

In my https://github.com/AArnott/Nerdbank.JsonRpc/ repo I have a much simpler JSON-RPC library than StreamJsonRpc makes possible, thanks to PolyType. The server-side is fully functional and quite nice. (It assumes Nerdbank.MessagePack as the serializer, which simplifies some things significantly, again thanks in part to PolyType).

The client side of the library though leaves more for the user to manually code than I'd like, however.

• This library currently requires all the arguments to be serialized as a map or array via a single declared type for which we have a type shape.
• The convenient calling pattern of invoking the RPC interface requires a proxy to be manually written that uses the argument type.

Here is a sample of the code the user must manually write for a one-method RPC interface:

internal partial class ServerProxy(JsonRpc jsonRpc) : IServer
{
	public ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken)
		=> jsonRpc.RequestAsync<AddArgs, int, Witness>(nameof(IServer.AddAsync), new AddArgs { a = a, b = b }, cancellationToken);

	[GenerateShape]
	internal partial struct AddArgs
	{
		[Key(0)]
		public int a;
		[Key(1)]
		public int b;
	}
}

I started exploring a source generator of my own that would activate when the user code has something like this:

[RpcProxy]
internal partial class MyProxy : IServer { }

The source generator would then emit a partial declaration that fills in the above code. The problem is the above code includes PolyType attributes, which as a source generator itself, means PolyType won't actually generate type shapes for this source generated code.

I'd like to explore whether PolyType could optionally generate a proxy for me, based on the user's partial declaration (so they can control which interfaces are implemented). It might look like this:

The user declares a partial proxy class like this:

[GenerateProxy]
internal partial class MyProxy : IServer { }

PolyType's source generator then emits another partial, like this:

internal partial class MyProxy : IServer
{
    private readonly IMethodInvoker invoker;

    internal MyProxy(IMethodInvoker invoker) => this.invoker = invoker;

    ValueTask<int> IServer.AddAsync(int a, int b, CancellationToken cancellationToken)
        => this.invoker.Invoke<ValueTuple<int, int, CancellationToken>, int>("AddAsync", (a, b, cancellationToken), GeneratedTypeShapeProvider.ABCTShape);
}

The PolyType library itself would declare this type:

public interface IMethodInvoker
{
    T Invoke<TArg, TReturn>(string method, TArg arg, ITypeShape<TArg> shape);
}

My library would then be responsible to implement IMethodInvoker, and its implementation would have used the type shape visitor pattern on the IServer interface (in advance) in order to construct that IMethodInvoker instance so that it knows how to handle all the methods.

There's an open question about how PolyType's source generator knows which of the interfaces are meant to be implemented by PolyType.
The way in which Nerdbank.JsonRpc would implement IMethodInvoker using the visitor pattern is a bit hand wavey at this point, but I suspect it could work.

Thoughts?

[teneko]

I tried to to follow, but pretty sure I miss something. When comparing to vc-StreamJsonRpc, you already have this pattern

[JsonRpcContract]
[GenerateShape(IncludeMethods = MethodShapeFlags.PublicInstance)]
interface IServer {
  ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken)
}

Then you allow me to acquire the typed proxy by doing var proxy = rpc.Attach<IServer>();

And often I need disposability, or extra functionality to one of the methods of IServer, so I typically implement a wrapper:

class ServerProxy(IServer inner): {
  ValueTask<int> IServer.AddAsync(int a, int b, CancellationToken cancellationToken) => await inner.AddAsync(a, b) + 1;
}

What do I miss?

[AArnott]

StreamJsonRpc's design is substantially more complex, but you're right in that it is possible to do JSON-RPC proxies without any further enhancement to PolyType. StreamJsonRpc doesn't take full advantage of PolyType though, and Nerdbank.JsonRpc is a fresh library that attempts to take full advantage of PolyType.
One of the design decisions in StreamJsonRpc that we made to support AOT proxies was around how to handle multiple RPC interfaces on a single proxy class. While I like what we came up with there, I'm interested in changing how the user expresses the set of RPC interfaces to a more standard C# pattern, which is to use a partial class declaration that we just populate.

In StreamJsonRpc, there are a lot of overloads to handle the various ways of invoking RPC methods from the client, involving no args, args by position, args by name, and with or without cancellation.
In Nerdbank.JsonRpc, I've cut way down on the number of RPC invoking methods on the client, by having always exactly one argument, which is either the args array or args object. But that means the args have to be declared as a type, which I don't want to require the user to do themselves. This is the part that really needs PolyType support to make happen.

But the rest of the proxy class would be nice to get as well.

[ZingBallyhoo]

Curious to see if there's a proper solution for this. It seems there's a few ways of having it work, but nothing perfect.

About handling arbitrary args, currently the way I'm solving this this is using function (delegate) shapes.

public interface IMyService
{
    public delegate ValueTask<int> AddAsyncDelegate(int a, int b, CancellationToken cancellationToken);

    public AddAsyncDelegate AddAsync { get; set; }
}

Using IFunctionTypeShape<>.FromAsyncDelegate you can build an instance of the delegate that processes the parameters & binds to your remote implementation. The delegate can then be assigned to the property. There's a somewhat example of this in JsonSerializer, although regarding events and not delegates:

PolyType/tests/PolyType.Tests/JsonTests.cs

Line 452 in da5ac94

AsyncJsonEvent onMethodCalledAsyncEvent = JsonSerializerTS.CreateAsyncJsonEvent(serviceShape.Events.First(m => m.Name == nameof(RpcService.OnMethodCalledAsync)), instance);

PolyType/src/PolyType.Examples/JsonSerializer/JsonSerializer.Builder.cs

Line 334 in da5ac94

functionShape.FromAsyncDelegate((ref TArgumentState argState) =>

PolyType/src/PolyType.Examples/JsonSerializer/JsonSerializer.Builder.cs

Line 102 in da5ac94

if (parameter.ParameterType.Type == typeof(object) && parameter.Name == "sender")

---

Of course, this is still not a proper interface type :') which makes it awkward to implement on the server side.
Maybe the ground truth could be an interface and then a proxy type with delegate members is generated? That would be more generic than passing a method name around. But it's the same issue with source-gen chaining for now.

[AArnott]

I already have the server side all figured out. The change I'm asking for is on the client side. Some class must be declared that implements the interface. Adding delegate members of that interface does not resolve that.

[ZingBallyhoo]

I mean to offer an alternative design to IMethodInvoker :). The interface with delegates is something that works today without proxies, not the desired outcome.

Maybe the ground truth could be an interface and then a proxy type with delegate members is generated? That would be more generic than passing a method name around. But it's the same issue with source-gen chaining for now.

[GenerateProxy]
[GenerateShape(IncludeMethods = MethodShapeFlags.PublicInstance)]
interface IServer
{
    ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken);
}

[GenerateShape]
partial class MyProxy : IServer
{
    public delegate ValueTask<int> AddAsyncDelegate(int a, int b, CancellationToken cancellationToken);

    public AddAsyncDelegate AddAsyncImpl { get; set; }

    public ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken)
    {
        return AddAsyncImpl.Invoke(a, b, cancellationToken);
    }
}

[AArnott]

The interface with delegates is something that works today without proxies, not the desired outcome.

I don't think so. At least, not the way I'm thinking of it.
If my library is to provide an instance of an interface, there must be an implementation of that interface. The members on that interface cannot possibly change that requirement. Even in your sample, you've declared an implementation of that interface (which you call MyProxy.

I suspect what you mean to say is that you only need one proxy implementation and it can serve for any implementation because the method bodies can be supplied at runtime. That's true for a subset of cases, but:

1. It doesn't allow a library that returns proxies to add additional interfaces to the proxy classes.
2. It requires an abnormal interface to triple up all methods delegate types and delegate properties. The interfaces that StreamJsonRpc supports are almost normal. Nothing new required, we just restrict what you can do in the interface (e.g. no properties, only async or void returning methods).

[ZingBallyhoo]

If my library is to provide an instance of an interface, there must be an implementation of that interface. The members on that interface cannot possibly change that requirement.

I think have I added a lot of confusion by making the <thing that defines delegate properties> an interface. That was just an arbitrary requirement I gave myself. I'll start from scratch here with proper examples.

public class Service
{
    public delegate ValueTask<int> AddAsyncDelegate(int a, int b, CancellationToken cancellationToken);

    public AddAsyncDelegate AddAsync { get; set; }
}

public class Service_Server : Service
{
    public Service_Server()
    {
        AddAsync = AddAsyncImpl;
    }
	
    public async ValueTask<int> AddAsyncImpl(int a, int b, CancellationToken cancellationToken)
    {
        return a + b;
    }
}

This is code that works today, but not code that I wish I could be writing.
The server implementation haphazardly assigns to the delegate members (which could be aided by generated code I suppose).
The client instance of Service is created via a PolyType visitor.

---

Via magic™️, maybe it would be possible to write this code

[GenerateProxy]
[GenerateShape(IncludeMethods = MethodShapeFlags.PublicInstance)]
partial interface IServer
{
    ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken);
}

public class Server : IServer
{
    public async ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken)
    {
        return a + b;
    }
}

And have <something> generate this code

[GenerateShape]
partial class ServerProxy : IServer
{
    public delegate ValueTask<int> AddAsyncDelegate(int a, int b, CancellationToken cancellationToken);

    public AddAsyncDelegate AddAsyncImpl { get; set; }

    public ValueTask<int> AddAsync(int a, int b, CancellationToken cancellationToken)
    {
        return AddAsyncImpl.Invoke(a, b, cancellationToken);
    }
}

The server implementation would implement the interface.
The client implementation would be an instantiation of the proxy with the delegate properties filled out.

How the the polytype shapes for the delegate members would refer back to the original definition (for attributes, original name, or anything else you would do with the methodshape) is an open question.

---

It doesn't allow a library that returns proxies to add additional interfaces to the proxy classes.

This is true if the proxy implementation is expected to resolved via magic (e.g var proxy = rpc.Attach<IServer>();) and not a concrete type (which could a user supplied subclass or wrapper, including something generated on top of the proxy). I'm not sure how the magic resolving would work in a non 1-to-1 proxy world anyway?

[AArnott]

It's interesting that you use the delegate pattern even for the server, though I haven't found that to be necessary or even useful since the RPC server is implemented directly by the user anyway.

For the proxy that the client uses, I can see it being useful because the user doesn't want to implement a mere proxy, as it is all boilerplate. The delegates allow anyone to implement the interface just be setting properties to delegates.
However even in your example you have [GenerateShape] on the proxy class, which prevents a source generator from being able to meaningfully emit it and have it used within the same assembly. And that is the whole point of this issue. And my proposal to overcome the problem is that PolyType write the proxy itself.

[teneko]

partial class declaration that we just populate

@AArnott can it be that you refer to the delegation pattern as for example implemented by Kotlin¹?

Footnotes

1. https://kotlinlang.org/docs/delegation.html ↩

[AArnott]

Not really. In that example the interface must still be implemented meaningfully, and a subclass declared.
What I'm asking for is a stub implementation so that I can provide a meaningful implementation that is all directed through a single method on a well known interface, such that it can be generated at runtime without dynamic code.