I come from a systems programming background with experience in using RPC. However, RPC in the traditional sense has always lacked things like subscriptions/callbacks to support more advanced interactions. Instead we have had to result to comet/long-poll and other such tactics which have many shortcomings. The other problem is that each RPC service listens on a socket for incoming connections. So when you have dozens of services this can quickly become tricky to deal with especially when you start looking at authentication. And finally, the unidirectional relationship imposed by the classic client/server model doesn’t really allow for bi-directional communication.
I am working on a project that consists of a dozen or so RPC services built upon msgpack-rpc. The services themselves run in a single process for ease of deployment. Some of these services talk to one another via the corresponding RPC clients which forms a hierarchy of sorts. The services learn about one another via a registry service. On startup, each of these services registers themselves with the registry. They then have the option to block and wait for other services to come online. This provides a means to synchronize services on startup. There is also a front-end that runs as a separate process space. Currently the front-end utilizes a few of the RPC clients to interact with the back-end services.
What I am looking at now is providing some kind of authentication mechanism between front-end and back-end to prevent unprivileged use of the services. In addition to this, I also want to be able to expose the API provided to the front end to third-party users. Perhaps even restrict capabilities/roles based on the level of authentication. This is proving to be a daunting task given that msgpack-rpc does not provide any sort of authentication mechanism and over and above that, any means to mediate based on roles/capabilities.
One approach I was looking at was to simply hide all of the RPC backend services behind a websocket API. Then the front-end can authenticate over a websocket, negotiate capabiltiies/role, etc. However, in order to do this I need to now introduce another service to mediate between the websocket to the front end and the RPC services on the backend. Plus, I also then need somehow secure each of the individual RPC services.
Note that I do not have any notion of a web front-end at this point in time and likely won’t. So I don’t need to “serve” anything to a web browser. However, it is a possibility that this could materialize in the future so it would be nice to keep that door open. I am now trying to decide if my architecture would be much simpler and more extendible if I went with Autobahn|Cpp and a WAMP Router. This would mean that I would have a single point of authentication since the only thing “listening for” and “accepting” connections would be the WAMP Router. Plus, the ability to now expose and manage an API to a third-party would be much simpler. It almost feels like a natural progression. Furthermore, the ability for full-duplex communication over the WAMP protocol greatly simplifies the notification/callback semantics. Currently this is unpleasant with msgpack-rpc.
Can you see anything here that raises a red flag where you would say, “don’t move to Autobahn|Cpp + WAMP Router”?
Does this seem like a logical architectural move even though I am not technically doing anything “web” based?
What kind of performance can I expect? Does the routing add significant overhead?
If I am working in a closed system (i.e. WAMP Router accepting only local connections), can I get away with writing a scaled down implementation of a WAMP Router natively in C++ using simple authentication.
Is it a common use case to have the WAMP Peers and WAMP Router all live together on one machine? same process space?
I appreciate any insights that the group can can offer.