Do you need some kind of tiny and fast RPC API?
Then MessagePack-RPC could be a good choice for you.
Let’s see the benefits:
- it’s simple, yet powerful and extensible (explained in detail below)
- fast: uses MessagePack – binary data serialization format (kind of “compressed” JSON, aims to be fast and lightweight)
- efficient: protocol does not restrict how response should be delivered to client, it’s up to you, if it is going to be synchronous delivery or asynchronous.
- cross-language: already has implementation for Ruby, Python, GO, PHP, Java, C#, C++, and even Haskell (of course it’s not a rocket science to implement own client)
Probably the most famous story about using MessagePack-RPC in “production” is neovim‘s story.
Neovim uses this protocol in order to communicate with remote plugins (e.g. plugin, written in other programming language than native VimL and executes as separate from vim process). Check this out if you are interested in details: https://github.com/neovim/neovim/wiki/Plugin-UI-architecture
The protocol defines 3 kinds of communication between client and server:
- request message
- response message
- notification message
Request and response messages should be pretty clear: when you need to initiate some server work, you send request message, and when it is finished, you receive response message. Notification message is kind of request message, but for cases when client does not need any response. Any message is an array of certain form, packed with MessagePack.
Let’s look more detailed:
type – it is 0 (integer,zero), which is mark that this is a request message
msgid – your message id, used to find out response for particular message
method – server method name, string
params – params for server method
type – it is 1 (integer,one), which is mark that this is a response message
msgid – id, corresponds to the request message
error – just nil if server method executed correctly and any object if not. Defining exact from of error value is up to user, for instance neovim respond with array of 2 elements: error code and text error message, explaining the error.
result – any object server method returned, up to user to defined it’s format.
type – it is 2 (integer,two), which is mark that this is a notification message
method and params has the same meaning as for response message
As it was said, protocol itself does not define any order for messages, and does not dictate should it be synchronous or asynchronous. As it comes from messages format it is technically acceptable to implement it in both ways.
Basically it’s a right choice when one need to communicate between 2 or more applications with tiny, asynchronous, frequent messages, like in:
- mobile games
- lightweight communication between processes (e.g. neovim case, inter-process communication for your own database implementation)
- sending different kind of metrics from your application for further analysis to some storage
- fast cache warming for web applications