Why JSON RPC?
● The simplest RPC (request, response) standard.
● Transport agnostic (supports “IP over Avian Carriers”, rfc1149)
● Uses good old JSON.
● Supports batch calls.
● Tiny specification
● Battle tested.
● While implementing communication protocol you can accidentally implement
own JSON RPC :)
What I want?
● Transport agnostic (WS, HTTP, HTTPS, MQTT, Avian Carriers, WebRTC etc)
● Multi transport mode with transport dynamic registration
● Bidirectional communication over the same channel
● Modern API
● Server and client both working in browser
● Lightweight, ideally core library with zero dependencies
● Easy to implement own transports (all hard things should be abstracted)
● Easy way to test new transports
https://www.npmjs.com/package/jayson - great library but rather coupled, hard to
extend, server requires all transports. It good for own use cases but not universal.
https://www.npmjs.com/package/jsonrpc-bidirectional - I’ve never thought that
JSON RPC can be so complex. Later about this.
https://github.com/teambition/jsonrpc-lite - just request/response serializer/parser
https://www.npmjs.com/package/modular-json-rpc - one transport example, does
not support multiple transports, batches not implemented, no tests, 2 stars on GH
https://www.npmjs.com/package/mqtt-json-rpc - leaky API, transport and payload
I tried a lot and was not able to find the right one
Use case 1: JSON RPC Over MQTT
Why to use: all your service needs is just a MQTT endpoint. After that it can
communicate with any service and any other service can communicate with it.
Your service can be same time client and server.
We use Mosquitto MQTT server with Mole RPC transport for MQTT
Why to use: your server is behind NAT/Firewall and you want to send request to
it. So, you server can connect to client via websocket and now client can send
requests to connected server as usual.
Here are working examples:
● Server connects to client
● Bidirectional calls
Use case 2: inversion of client and server
Use case 3: send tasks to browser Web Worker
Why to use: everytime using web
workers you will need match
request and response. You can do
it with own protocol or use feature
rich, spec compliant Mole-RPC
with Web Worker transport
3.5kb (min+gzip) client build
< 2kb (min+gzip) server build
JS features that allow to build better abstractions in MoleRPC
Promises + Async/Await
Symbols (for providing access to metadata during request)
What is next?
Improve documentation, add more examples.
Release v1.0 with finalized API. MoleRPC itself is almost finalized but some
features can be added to transports.
Improve existing transports.
Create more transports: HTTP(S), TCP, WebRTC
More production testing etc