It would be nice to see what kind of performance this gets. How many requests per second, number concurrent requests, request timings, memory usage, proc usage, etc. I haven't done this enough in my career to have confidence in the benchmarks I would produce so handing this over to someone who has done it before.

I wasn't feeling creative enough to come up with a good name when I created the project. I named it the first thing that popped into my head. Since then I've thought of some better names and would like to open it up to a vote. Leave a comment for which one is your favorite!

• InterfaceRpc
• rpc-net
• nRPC (n is for .NET)
• dotRPC
• QuickRPC
• qRPC (the q is for quick)
• iRPC (the i is for interface)
• RPC.Net

Other suggestions welcome!

It would be cool for someone to create a sample service and write about how they published it to Azure.

Other deployments welcome as well: Kubernetes (could be on any cloud provider), GCP, AWS

This would force interfaces to only have one parameter, aka, the "request" object. So instead of

public interface IUserService
{
    User CreateUser(int id, string firstName, string lastName);
}

you would have this

public interface IUserService
{
    User CreateUser(CreateUserRequest request);
}
public class CreateUserRequest
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

PROS:

• Interfaces are less prone to breakage
• Sets a standard way of doing things
• Is easier to deserialize, potentially

CONS:

• Existing interfaces can't easily use the library

What else should be considered? Is this a good idea?

Create nuget packages and publish to nuget.org. There will be 2 packages - 1 for the client and 1 for the server.

Deserialization on the service only works for JSON. When I try it with protobuf the service crashes trying to deserialize the request.

This could be a major refactor from what I started with.

Also the reflection I used isn't well optimized. This could potentially go away with a refactor or just made to perform better if any of it is reused.

Idea would be to have an attribute that could be applied to interface methods. Something like:

[RpcCache]

And would signify to the client that it can cache the response for a certain amount of time.

The server when reading this attribute would add a Cache-control header to the response with a max age of however long the client should cache it for.

The default behavior will be to cache by every parameter value allowed by the method. Optionally the attribute can accept only the parameter names that should be used to lookup the cache response. Something like:

[RpcCache("Id", "UserName")]

The client will know of the cache attribute and parameters the same as the server since they both use a shared interface.

There should probably be a global setting for cache time - and a per-method/attribute override of that value. Something like:

[RpcCache(new TimeSpan(1, 0, 0))]

Open Questions

1. Should there be a way for the client to override the cache and make the call anyways?
2. Should the server should also cache the response and resend it if appropriate?
3. Should there be a way to invalidate the server cache/force the server to call the interface's implementation if # 2 is Yes.

Not sure how feasible this is because the library currently expects there to be a shared interface among server & client. You wouldn't be able to share a .NET interface with other languages directly. It may take #4 being done first.

Placeholder. Have to think about this.

Would like for .proto definitions to be dynamically generated based on the type of interface and served via an endpoint on the service. Unsure of what the endpoint should be called... I was thinking "/Proto" but that could be the name of a method, so maybe not. It could contain an additional slash "/Util/Proto" or hyphen "/Util-proto" which would guarantee no collisions. Thoughts?