[HN Gopher] Crossbar.io - an open source platform for distribute...
___________________________________________________________________
Crossbar.io - an open source platform for distributed and
microservice apps
Author : gjvc
Score : 65 points
Date : 2021-05-07 17:57 UTC (5 hours ago)
(HTM) web link (crossbar.io)
(TXT) w3m dump (crossbar.io)
| no_wizard wrote:
| Only 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/
| holler wrote:
| > 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.
| no_wizard wrote:
| I'm using SSE to push _from the server_ to the client. I 'm
| just sending normal HTTP requests to send from _the client_
| to the server, as they 're much smaller in volume.
|
| Its really...simple. SSE streams are unidirectional so you're
| only listening for incoming messages, never outgoing on the
| client, conversely, you just broadcast out to your clients
| over SSE. Just have an HTTP/2 connection makes it even more
| efficient.
|
| Its not great if you need users to have multi-tab workflows
| (you can only have 6 connections over HTTP 1.1 for a single
| user), but that has not been an issue for us. There's some
| logic you can do on the backend to close duplicate
| connections.
|
| When Web Transport hits, I'm hoping we can do SSE on the
| client as well, and have two separate unidirectional (one for
| the server to push to the client, one for the client to push
| to the server) and have SSE both ways, this way we can
| terminate the streams independently for efficency
| frankwiles wrote:
| We use Crossbar and WAMP to build Simpl (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).
| kitd wrote:
| Maybe I'm just getting old, but can someone explain what this is?
| Some kind of message broker? "Networking platform" is too vague.
| tegeek wrote:
| So 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 wrote:
| Thank you!
| lostcolony wrote:
| That'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 wrote:
| Please 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.
| ForHackernews wrote:
| > Please do not associate your comment with "just getting
| old"
|
| > If you are familiar with 1990s technology
|
| Is this extremely-subtle trolling?
| nly wrote:
| Once 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).
| gjvc wrote:
| > Please do not associate your comment with "just getting
| old". This sort of comment unnecessarily perpetuates negative
| stereotypes in the industry.
|
| +10000
| drdaeman wrote:
| I'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.
| gumby wrote:
| Used in a couple of packages over the last few of years and it
| worked pretty well. Pubsub & rpc over web sockets.
| polskibus wrote:
| what are the delivery guarantees? Is it at-most-once only?
| holler wrote:
| > 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#fea...
| omneity wrote:
| I 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 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 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 wrote:
| I don't see this fitting into the factory space for large orgs,
| if you have one factory you'll probably have many
| omneity wrote:
| My 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 wrote:
| > _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.
| f430 wrote:
| Unfortunately the Open source industry has been hijacked by
| VCs. They are polluting the space by chasing quick dollars
| and confusing developers and users.
| iAm25626 wrote:
| build 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
| holler wrote:
| When 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.
| larrykubin wrote:
| I 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
___________________________________________________________________
(page generated 2021-05-07 23:00 UTC)