The case for/against a WebSocket Plugin API

[edaniszewski]

There has been talk about this a couple of times for various reasons. The verdict was that it is currently out of scope, but something to investigate in the future. The discussions around it were not tracked, so this issue is being opened to track some of the rationale behind the idea.

Pros

• Generally easier to debug API issues since (a) there is limited grpc experience at the company (b) grpc uses a binary format for transport
• Its a bit easier to define a JSON message scheme than a protobuf scheme (and allows us to more easily have some unstructured nested data, e.g. map with arbitrary values)
• makes it easier to interrogate plugins directly for debugging, etc
• VASTLY simplifies synse-server's monitoring of plugin connectivity status. the websocket connection can be used to determine whether the plugin is connected/responsive. this also would allow synse server to know a plugin disconnected in real-time

Cons

• It is a complete rework of the internal plugin API transport. The modeling would generally stay the same, but on the Synse Server side, this would mean changing the client used to communicate with plugins, the data model returned from the client, etc. In general these are not big changes, but they are changes. On the plugin side, the changes are a bit more extensive, as the grpc server there would need to be entirely replaced with a websocket server.
• In theory, this could mean more network pressure, as grpc is a compact binary message format, where a JSON payload for a websocket api is less so. Practically, I'm not sure how much this would actually impact us, if at all.

Other things may be added to these lists as time goes on. This is just a single place to start collecting thoughts on it.