7 ms·
Crossbar.io – an open source platform for distributed and microservice apps
- 120bits 6y agoSlightly off topic. I really like the step by step animation they have on the site. Can anyone tell me how I can build something like that. I'm learning WebGL and Three.js, not sure if that's what its uses.
- iAm25626 6y agobuild on top of WAMP: Web Application Messaging Protocol https://wamp-proto.org/comparison.html Another alternative that I follow with great interest: https://github.com/nanomsg/nng pubsub is a powerful pattern
- drdaeman 6y agoI'd wish people presenting their frameworks would not just describe the happiest path, but the outage modes as well. I'm looking at that "Powering the Internet-of-Things" animation on their main page, and immediately asking myself "what if there's a network outage just as the temperature rises?" "what if the fan controller has a power hiccup and fails to start?" etc etc. Because those days it takes days (or even weeks) to subscribe to the idea, build a sketch and start testing failure scenarios.
- kitd 6y agoMaybe I'm just getting old, but can someone explain what this is? Some kind of message broker? "Networking platform" is too vague.
- lostcolony 6y agoThat's what I'm getting from it, message broker. It says pub/sub and 'routed RPC', wherein a client can register a method and another client can call it...but that's achievable with pub/sub anyway so not really sure what the benefit is.
- deadmutex 6y agoPlease do not associate your comment with "just getting old". This sort of comment unnecessarily perpetuates negative stereotypes in the industry. And to answer your question, crossbar is an implementation of WAMP (Web Application Messaging Protocol) that is built on top of web sockets. If you are familiar with 1990s technology, think TIBCO for the web. We used it at a startup in the mid 2010s, and it was great for real time communication between clients (browsers) and servers. Never had any issues.
- gjvc 6y ago> Please do not associate your comment with "just getting old". This sort of comment unnecessarily perpetuates negative stereotypes in the industry. +10000
- ForHackernews 6y ago> Please do not associate your comment with "just getting old" > If you are familiar with 1990s technology Is this extremely-subtle trolling?
- nly 6y agoOnce upon a time I used WAMP as an IPC and routed RPC protocol between a bunch of _desktop_ processes. Like dbus but not awful to use, and naturally cross platform (because it's over TCP).
- tegeek 6y agoSo at high level its Pub/Sub and RPC combined together in a single framework. From a developer perspective, you can create a "channel" and then start transmitting messages on that channel. Then someone else can subscribe and can listen to that channel. In the same way, someone can "expose" a single method. And you as a developer can call that method from anywhere. The medium of communication is WebSockets. The protocols it uses is WAMP. Which means any programming language can implement this (on top of WebSockets) and can take advantage of "distributed application architecture".
- kitd 6y agoThank you!
- gumby 6y agoUsed in a couple of packages over the last few of years and it worked pretty well. Pubsub & rpc over web sockets.
- polskibus 6y agowhat are the delivery guarantees? Is it at-most-once only?
- holler 6y ago> Instead of complex QoS for message delivery, a Broker may provide message history. A Subscriber is responsible to handle overlaps (duplicates) when it wants "exactly-once" message processing across restarts. The Broker may allow for configuration on a per-topic basis. -------- Slightly confused, my impression is that it's At Least Once with the client responsible for dedupe, but it says "if you want exactly once", so I'm not sure if the client is supposed to make a second request for confirmation? https://wamp-proto.org/_static/gen/wamp_latest_ietf.html#feature-definition-15 https://wamp-proto.org/_static/gen/wamp_latest_ietf.html#fea...
- gumby 6y agoIt’s possible to have the broker retain the messages and replay for new subscribers. If yiu lose connection and reconnect its your responsibility to filter out the ones you’ve already heard.
- no_wizard 6y agoOnly big downside to this (its WAMP[0] under the hood) from when I implemented this, and ultimately abandoned was the following: - The clients are huge. I should preface I'm a Software Engineer that focuses on the web, so this matters a lot to me. They really need to be run in a web worker if used, (they're 1MB + of JS, and don't tree shake well. They don't export ES Modules either, last I checked). We have real time chat infrastructure for context. Web Socket Support in Workers Can be weird too - There's no fall back to a different protocol in a practical sense (yes, the specification does not state it has to be websockets, it just defaults to web sockets). Its for all practical purposes, web sockets or bust. Why this matters to me? Because Server Side Events would be a more efficient way to push messages to clients when the total volume of pushes is several factors greater than pulls, from the server side. That is, the server in aggregate is going to push more data to all the clients than any one client is going to push to the server. Therefore, it would have been nice for this to be abstracted around different models for flexibility of architectural approaches. Ultimately we did go with an SSE push (from the server) model, and just send individual requests via HTTP Requests. It actually was less load on the server and faster over all (updates were still extremely fast, but no one client was ever pushing to the server more than the server was pushing out to them) [0]: https://wamp-proto.org/ https://wamp-proto.org/
- holler 6y ago> There's no fall back to a different protocol in a practical sense (yes, the specification does not state it has to be websockets, it just defaults to web sockets). Its for all practical purposes, web sockets or bust. Why this matters to me? Because Server Side Events would be a more efficient way to push messages to clients when the total volume of pushes is several factors greater than pulls, from the server side. That is, the server in aggregate is going to push more data to all the clients than any one client is going to push to the server. Therefore, it would have been nice for this to be abstracted around different models for flexibility of architectural approaches. That sounds interesting! I've implemented mqtt in a chat project but have not investigated SSE as a fallback/hybrid approach. Are you only using SSE or hybrid? I guess I need to read more about SSE but I am curious to compare it to websockets/mqtt and learn tradeoffs.
- omneity 6y agoI used crossbar at multiple occasions in projects of various complexity. My main take away: - Pleasant to use and does almost exactly what it advertises - Interesting authentication & permission patterns, unfortunately we couldn't extend it to the frontend, and that left us with a strange gap - Hard to scale for serious cases, clustering is impossible in the open source edition and the commercial version costs in the 5 figures per cluster node Ultimately I am quite confused about the target demographic of Crossbar (factories moving to IoT?) I don't know of many pubsub + rpc solutions targeting a similar tradeoff with a tight packaging and a similar learning curve. Here are some I found then: https://deepstream.io https://deepstream.io is the closest and has a richer feature set (including a replicating document store), however it seems to have a small ecosystem / community / limited support options, and permissions do not seem as advanced. https://nats.io https://nats.io is close but lower level. Has a large community and rich ecosystem however. Then you can also mix and match lower level technologies to achieve the particular set of tradeoffs you need. MQTT, AMQP, WS as the protocol, mosquitto / rabbitmq / zeromq, then json-rpc on top, grpc ...
- hhh 6y agoI don't see this fitting into the factory space for large orgs, if you have one factory you'll probably have many
- omneity 6y agoMy wording might have been ambiguous. I am sure you can scale Crossbar if you get the commercial version which supports clustering (hence IoT factories), however the open source edition is limited to a single running instance.
- sneak 6y ago> Hard to scale for serious cases, clustering is impossible in the open source edition and the commercial version costs in the 5 figures per cluster node I'm really tired of these fake open source projects. If you really believe in software freedom, you simply don't build or distribute proprietary software. Open core is bullshit. It's like a free software kernel distributed with a closed source libc. Nobody would call that project open source.
- holler 6y agoWhen I set out to build a new realtime chat app, I explored various options and landed on wamp/crossbar.io as a potential choice. This was a few years ago but at the time it seemed promising, reasonably well-documented, and had both python and js clients. One problem was whether it would support horizontal scaling if you needed to expand beyond a single node, and at the time they were "working" on a global/cross router but it wasn't ready. It's a hard problem to solve and one that may not be required for many use cases. I'm not sure if they delivered it but I ended up going with mqtt instead. To piggyback on another commenter, their javascript library did feel a bit bloated/dated, but I also got the impression a few of the people were juggling a lot of related projects and maybe there wasn't enough of a community. Haven't checked back recently. In any case, the project is still impressive, has some dedicated people behind it, and could be a great solution to add websockets to a project.
- frankwiles 6y agoWe use Crossbar and WAMP to build Simpl (https://simpl.world/ https://simpl.world/) on overall it's been a great experience. Definitely suffers from some of the challenges mentioned above (commercial clustering, large-ish frontend libraries, etc) but it's been pretty straight forward to work with and scales up well enough for our needs (a few hundred to a few thousand simultaneous concurrent players).
- larrykubin 6y agoI used to work at a SaaS startup that used this extensively. Here's a demo of a remote command line tool we made - React on the frontend communicating with C++ agents on desktops. The desktop agents could also publish events that the web could subscribe to and show activity on a real-time feed / dashboard. https://www.youtube.com/watch?v=SNjzPS1zmkg https://www.youtube.com/watch?v=SNjzPS1zmkg
- beagle3 6y agoCan anyone with experience in both crossbar and 0mq and/or nng share when one would prefer one over the other (or are they essentially equivalent)?
- LeSaucy 6y agoOne thing I like about crossbar is the meta-events system. Being able to run a callback when some else subscribed to a topic has been super useful to only do work when someone is interested/subscribed.
- paraknight 6y agoI don't get it, why not just use MQTT? That has WebSockets support too. Is this reinventing the wheel or is there some advantage?
- RedShift1 6y agoOff topic but which MQTT broker do you use?
- paraknight 6y agoJust bog-standard Mosquitto, haven't tried anything else since it does the job great
- RedShift1 6y agoI miss the ability to see which clients are online and to what they are subscribed to. I'm using VerneMQ because it has that ability but it has its quirks.
- samoit 6y agoJust use eclipse mosquitto: Free for all use cases and more performant. https://mosquitto.org https://mosquitto.org