4 ms·

If you want RPC and PUB/SUB over Websocket, you have the "Web Application Messaging Protocol" standard, which has implementations for Python, JS (node and in br

If you want RPC and PUB/SUB over Websocket, you have the "Web Application Messaging Protocol" standard, which has implementations for Python, JS (node and in browser), PHP, C# and Java. Checkout the main router, it's open source and handles a decent 6k msg/sec on a raspi: https://crossbar.io/ https://crossbar.io/ The best things about it is that you don't have to write the message schemas in advance, only the function signatures.

polskibus 8y ago
Thanks a lot, I'm a bit worried about performance here, I wonder how does it compare against standard REST and SignalR in terms of number of active connections, performance, etc.
- sametmax 8y ago
  The general rule of thumbs is that Websocket are cheaper if you want long connection with states to maintain (you only need to identify once) or have a lot of small messages. However, you have a low number of requests, or big requests, REST is going to be faster. But as usual, it depends of your implementation and your constraint. After all, facebook is using polling if I recall.
GordonS 8y ago
Looks interesting. How does this compare to RabbitMQ or MQTT?
- sametmax 8y ago
  It's a bit more performant than MQTT, but it eats more ressources (bandwidth and cpu). It's still practical for IoT (although I use it for the Web), as the C++ implementation (https://github.com/crossbario/autobahn-cpp https://github.com/crossbario/autobahn-cpp) targets embeded systems. However, it uses boost, so it won't fit in extrems memory requirements. All it all, if your configuration allows it, it's way, way easier and more flexible than MQTT to use. Combared to RabbitMQ, it's not as fast. You can't beat years of optimized Erlang and field testing by fortune 500. Yet, Rabbit MQ is very low level: you need to setup queues, and consumers, and if you need RPC with returned value you will add manual logic on top of it. Don't get me started if you want to load balance consummers. Real life AMQP is hard. Comparatively crossbar offers a great out of the box experience. All in all, I'd say the sweet spot for the tech is between the arduino/raspi and an average website/company micro service archi. If you have very small hardware, MQTT could fit in the tiny space, and if you have a 100 message highways interconnecting your data centers around the world, you may want AMQP. Between those, crossbar.io is great.

polskibus 8y ago

Thanks a lot, I'm a bit worried about performance here, I wonder how does it compare against standard REST and SignalR in terms of number of active connections, performance, etc.

sametmax 8y ago
The general rule of thumbs is that Websocket are cheaper if you want long connection with states to maintain (you only need to identify once) or have a lot of small messages. However, you have a low number of requests, or big requests, REST is going to be faster. But as usual, it depends of your implementation and your constraint. After all, facebook is using polling if I recall.

GordonS 8y ago

Looks interesting. How does this compare to RabbitMQ or MQTT?

sametmax 8y ago
It's a bit more performant than MQTT, but it eats more ressources (bandwidth and cpu). It's still practical for IoT (although I use it for the Web), as the C++ implementation (https://github.com/crossbario/autobahn-cpp https://github.com/crossbario/autobahn-cpp) targets embeded systems. However, it uses boost, so it won't fit in extrems memory requirements. All it all, if your configuration allows it, it's way, way easier and more flexible than MQTT to use. Combared to RabbitMQ, it's not as fast. You can't beat years of optimized Erlang and field testing by fortune 500. Yet, Rabbit MQ is very low level: you need to setup queues, and consumers, and if you need RPC with returned value you will add manual logic on top of it. Don't get me started if you want to load balance consummers. Real life AMQP is hard. Comparatively crossbar offers a great out of the box experience. All in all, I'd say the sweet spot for the tech is between the arduino/raspi and an average website/company micro service archi. If you have very small hardware, MQTT could fit in the tiny space, and if you have a 100 message highways interconnecting your data centers around the world, you may want AMQP. Between those, crossbar.io is great.