Security News
OpenJS: “XZ Utils Cyberattack Likely Not an Isolated Incident”
OpenJS is warning of social engineering takeovers targeting open source projects after receiving a credible attempt on the foundation.
mole-rpc-transport-mqtt
Advanced tools
Weekly downloads
Readme
Mole-RPC is a tiny transport agnostic JSON-RPC 2.0 client and server which can work both in NodeJs, Browser, Electron etc.
This is MQTT based tranport but there are many more transports.
What is the reason of using MQTT for JSON-RPC?
MQTT is a standard broker in IoT world. It is lightweight and fast message broker and the same time it contains a lot of advanced features like (persistence, retained messaged, QoS, ACL etc).
You can organize many to many RPC-connunication between microservices via MQTT.
For example, in our case, we use this module to connect microservices deployed to an IoT Hub
Which MQTT server to use?
You can use anyone you wish. As for us, we use in production:
The easiest way to start playing is to run mosquitto in docker:
docker run -it -p 1883:1883 eclipse-mosquitto
After that you can try the example below.
const MoleClient = require('mole-rpc/MoleClient');
const MoleServer = require('mole-rpc/MoleServer');
const MQTTTransportClient = require('mole-rpc-transport-mqtt/TransportClient');
const MQTTTransportServer = require('mole-rpc-transport-mqtt/TransportServer');
const MQTT = require("async-mqtt");
async function main() {
await runServer();
await runClients();
}
async function runServer() {
const mqttClient = MQTT.connect("tcp://localhost:1883");
const server = new MoleServer({
transports: [
new MQTTTransportServer({
mqttClient,
inTopic: 'fromClient/+',
outTopic: ({inTopic}) => inTopic.replace('fromClient', 'toClient')
})
],
});
server.expose({
getGreeting(name) {
return `Hi, ${name}`;
}
});
await server.run();
}
async function runClients() {
const mqttClient = MQTT.connect("tcp://localhost:1883");
const client1 = new MoleClient({
transport: new MQTTTransportClient({
mqttClient,
inTopic: 'toClient/1',
outTopic: 'fromClient/1'
}),
});
const client2 = new MoleClient({
transport: new MQTTTransportClient({
mqttClient,
inTopic: 'toClient/2',
outTopic: 'fromClient/2'
}),
});
console.log(
'CLIENT 1',
await client1.callMethod('getGreeting', ['User1'])
);
console.log(
'CLIENT 2',
await client2.callMethod('getGreeting', ['User2'])
);
}
main(console.log, console.error);
MQTT has topics.
Different services can subscribe to different topic.
You can use wildcard characters in names like +
or #
.
MQTTTransportClient has two topic related parameters:
outTopic
- sends request to this topic.inTopic
- gets response in this topic.MQTTTransportServer has two topic related parameters:
inTopic
- listend to requests from client in this topic. outTopic
- sends response to this topic. Also, both MQTTTransportClient and MQTTTransportServer support inQos
and outQos
parameters
to control the quality of service.
MQTT version 5 supports the responseTopic
property in-built to the protocol.
The MQTTTransportClient will automatically pass it to server, therefore
you can omit specifing outTopic
for MQTTTransportServer in this case.
One of the pattern can be the following:
rpc/${FROM}/${TO}
rpc/${TO}/${FROM}
See "Usage Example" for a simpler approach
Let's assume that is an authentication server
Server:
const inTopic = 'rpc/+/auth-server';
const outTopic = inTopicToOutTopic;
function inTopicToOutTopic({ inTopic }) {
const [ namespace, from, to ] = inTopic.split('/');
const outTopic = `/${namespace}/${to}/${from}`;
return outTopic;
}
Client
const clientId = 'client123'; // you can use UUID for automatic id generation.
const inTopic = `rpc/auth-server/${clientId}`;
const outTopic = `rpc/${clientId}/auth-server`
So, for each clients connection to server you will have a pair of topics.
It looks a little bit more complicated but allows easely switch to many-to-many connection apprach.
For this case, you can use the same approach as for "Many RPC clients and one RPC Server" case.
You can notive that if SERVICE_A talks to SEVICE_B we need 2 topics.
But when SERVICE_B talks to SERVICE_A we will use the same topic names and that is ok.
This transport handles this situation, so you can use understandable topics which always follow this pattern:
rpc/${FROM}/${TO}
rpc/${TO}/${FROM}
This is the approach we use for many-to-many communication approach but you can use other approaces.
For example, if you want to allow SERVICE_A to get request only from SERVICE_B,
you can use inTopic name without wildcard - rpc/SERVICE_B/SERVICE_A
(outTopic can be set to static value rpc/SERVICE_A/SERVICE_B
as well ).
FAQs
MQTT transport for Mole-RPC (JSON RPC library)
The npm package mole-rpc-transport-mqtt receives a total of 77 weekly downloads. As such, mole-rpc-transport-mqtt popularity was classified as not popular.
We found that mole-rpc-transport-mqtt demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
OpenJS is warning of social engineering takeovers targeting open source projects after receiving a credible attempt on the foundation.
Company News
Come meet the Socket team at BSidesSF and RSA! We're sponsoring several fun networking events and we would love to see you there.
Security News
OSI is starting a conversation aimed at removing the excuse of the SaaS loophole for companies navigating licensing and the complexities of doing business with open source.