I talked about this a bit here https://news.ycombinator.com/item?id=31855604 and here https://news.ycombinator.com/item?id=25186586, which I'll reproduce for convenience:
>Expose a "REST" API and webhooks and you can have practically as many clients or "integrations" as you want.
>Here are design principles:
>- Anything you can do with point and click, you must be able to do with an API call.
>- It should theoretically be possible to clone your product using its API.
>- Users can be anything (people, systems, your own product). For example, our product is built using a plugin architecture, our subsystems hit our API.
>- Someone interested in an event should get that event and be able to subscribe to it. (Again, users can be people or systems, and that event could be the basis of some downstream actions).
Another one I shared elsewhere: It should be as easy to add functionality as it is to remove it. (functionality is in plugins loaded by a core, added and removed from a config file).
On the plugin architecture:
>One of the best, and first, things we did when starting our machine learning platform was to design it using a plugin architecture. There's a lot of scar tissue and horrible experience through our previous ML products we built for enterprise.
>Namely, it was extremely hard to onboard new developers to work on the product. They had to understand the whole thing in order to contribute.
>Changing something was also hard, since it was intertwined. Adding a feature or removing a feature was hard. Especially given the fact we were not designing to spec, and the domain experts we were building for could not give feedback. That was a constraint outside of our control, so we were building for users we never met based on what we thought would make sense.
>The first commits on our own platform were to establish a plugin architecture. There's a core, and there are plugins. We could add or remove functionality changing a config file. Applications are plugins and onboarding is easy and smooth, since a junior developer can start working on one plugin and then expand their knowledge.
>We're reaping the rewards of that.
These were some of the best decisions I've made.
PS: Have a look at https://jwt.io
If you need to perform real time messaging between two servers use either RPC or WebSockets. These are bidirectional messaging in binary without a round trip or large plain text header. What the data is, where it comes from, or how its generated is completely irrelevant to the transmission.
I have a Node.js app written specifically for this scenario. You can try my app to see if it solves for your use case. It is designed right now to support file system streaming, text messaging, status messaging, and so forth. It can be supported to messaging anything you need. Remote instruction execution will require more effort for security reasons.
https://github.com/prettydiff/share-file-systems