Client/Server Protocols

I've been thinking for a while about how server/client communication will need to occur in several different directions.

This front-facing use-cases are the APIs to the various servers (Kudo, World, Entity, Avatar), and have thought that these need to be rather high-performance.   I've been looking to newer alternatives to json and xml and all of the old paradigms for web-api serialization, so I've been looking at things like Protocol Buffers, Cap'n Proto, and FlatBuffers.   The first and third are Google supported.  I'm also interested in the meta level of having an RPC layer like gRpc, and this supposedly can use ProtoBuffs and FlatBuffers.  Cap'n Proto also has an RPC functionality (though not that I can see for c#).

Many of the API calling code will be built into the browser and so interfaces would be totally static (though versioned probably).

The other big client-server interaction is between servers and the Emissaries...   Much of the design of this architecture is inspired by the DDP model in the Meteor Framework.   However, I think the kind of information that gets synchronized between the server and the Emissary is a little different.   Simply doing a two way reactive subscription to a chunk of a Mongo collection isn't the best model for the Emissary.   Reactivity: yes, Synchronization: yes, but the data is more specialized. 

And, for the Emissary, most of these protocols have a schema language and generates classes that you use in the tool-chain to build the emissary.  These can't be compiled into the browser, and so have to run in the Emissary code with probably some high level communication -- perhaps passing the websocket handle down to the code.   So, likely there will be some specific hooks in the APIs for this code.

I'm still looking for a sync model I like, though due to the nature of the way the Emissary is setup, you really can roll your own if you like as long as the API is giving you enough rope for you to pull on.  And this is obviously one of those points where security is vital.  I think the idea was that the browser would set up the secured channel, and then the emissary can do what it needs.

I'm getting to the point where I need Hello-World functionality from all of the basic servers, so I need to get the infrastructure ready to go.   I need some very basic functionality from them as well.  I need World to get me an inventory, then I need to marshal all those entities from an entity server.  I can skip some of the security stuff in the Kudo server, but I'd like the Cert Chain for the Emissaries to be checked (right now, it will simply accept the cert I give it -- it has to be signed, but it makes no checks to verify who signer is and that the cert chain goes back to the Manufacturer Guid (and that the signer is authorized to sign for it)).

I'm also thinking I may need a "Server Common" project.   Simple "Common" might include stuff that the browser doesn't really need.