I really like that the documentation is quite honest and unbiased. Like with the integrations: https://deepstream.io/tutorials/integrations it always mentions downsides next to the upsides.
This is a really good point actually. I particularly liked the overview of other realtime libraries[1] for the honesty factor, and it really helped me understand how it relates to more familiar frameworks too.
This is great! I wish somebody would write a Firebase API compatible wrapper around this so escaping Firebase lock-in would be possible without altering code.
yup, that's not too far off. It also gives you Pub/Sub and Request/Response though. Also Firebase uses one huge data-structure for data-sync whereas deepstream breaks data down into smaller objects called "records" with individual lifecycles
Huh. I visited your site and reading the tag line "a fast, secure and scalable websocket & tcp server", I assumed it was just a socket server and had no idea it was actually a data-store.
While it looks interesting, I honestly don't feel like building a system like this on top of node. Not because of the library itself, which seems properly implemented (hard to see libraries using proper formatting and JSDoc these days).
node is a simple, friendly technology, until you to profile it. Then it's not so friendly. With a realtime system you require a great deal of profiling and quite honestly the tooling is not there.
"Oh but what about Flamegraphs and DTrace?"... it is nothing compared to what you have in Java. And node tooling is better on obscure operating systems like IllumOS.
If I had to implement a system like this I would opt for Scala + Akka, or Elixir/Erlang. If it's for simplicity/budget reasons, try PubNub.
I'm afraid I don't know too much about centrifugo, but it looks like a pub-sub server you can connect to Redis. deepstream on the other hand provides datasync (stateful, persistent JSON objects you can subscribe and listen to), request-response and pubsub in a scalable way with granular permissions and authentication strategies and an ecosystem of connectors that make it work with different databases, caches and message buses.
Looks quite interesting, I was evaluating few real-time frameworks (esp socket.io) for the past couple of days . Could you pls shed some lights on how easy to use deepstream to setup a one-to-one in-app chat/messaging setup for android? I guess its the event's are the way to go.
For eg:
client.event.subscribe('channel1', eventCallback)
client.event.emit('channel1', 'hello how are you?')
How scalable is that? can it support thousands of channels without any hiccups on a single medium digital ocean instance?
It scales very far. We've conducted benchmarks lately that showed that a single deepstream on an AWS t2.medium instance can comfortably handle 160.000~200.000 messages a second and a cluster of six ~ 4 Billion an hour. Please find the detailed results here
Sorry, I should have been clearer. I don't mean "does Deepstream tell the user when it's disconnected", I mean:
Does the Deepstream client have a facility (like Firebase) to instruct the remote server to perform an action in the event the client disconnects in the future and the client is unable to get any further message to the server?
ehm...this is not Horizon. But its a good question none the less. No, it does currently not have that facility, but it would certainly be a good addition
Could you please shed some light on concurrent connections benchmarks ? Im looking for a scalable solution - I am trying out socket.io and I read from others there are some performance issues as it scales.
How does this compare to something like ShareDB (https://github.com/share/sharedb)? It seems on the face of it that the data part of it is pretty similar (albeit Deepstream is more fully featured with auth etc.), however, there is no mention of how Deepstream handles conflict resolution if two clients are modifying the state.
Internally ShareDB uses Operational Transformation with special operations which are designed for use in JSON documents.
Wow, deepstream looks really good (and I'm a competitor, http://gun.js.org/ ). Your guy's product seems to have significantly matured over the last year. I'm very impressed! Up for chatting? mark AT gunDB DOT io (I still like your guys old website better though with the server/client graphic animation).
Ooh, thanks so much. Just heading out for the inevitable "we've made the frontpage drink", but let's get in touch tomorrow. The diagram is still there, but buried in https://deepstream.io/tutorials/core/cluster-messaging/
Yeah that one! I love that graphic! Your profile doesn't have your email address in it, so you'll have to ping me. Tomorrow sounds good. Congrats on the launch!
I love NodeJS. So many NPM's to be had. I want to open source our ANSI-C Realtime Server - maybe someday. Our https://www.pubnub.com/blocks-catalog/ BLOCKS engine actually starting in Java. That was a M-I-S-T-A-K-E-E-E-E. It's better now.
I like it but coming from socket.io I have a hard time with it. For instance, Where/how would I put my server logic? The "Node API" as its called isn't really helpful or not documented enough. But then again, I could have misunderstood what deepstream is all about or how you are supposed to be using it.
It's a different beast from socket.io :-) your server logic is just another client, written in java or node. There's a lot of functionality that let's you listen in on what clients request etc. Please find more details at https://deepstream.io/tutorials/core/active-data-providers/
Exactly word "probably" is a deal breaker in this case. I am also curious how someone was thinking JS will be a good idea for such project. But hey, there are people building cars out of plastic bottles...
It seems like you have to wait some seconds for the server to process the comment, if you refresh it should let you comment again. Anyway, looking forward to the data release, through a blog post I suppose?
Nice, really appreciate the progress here! However, is there any reason the artifacts aren't on github? It may be more convenient when it comes to issues/changelogs etc.
agreed, they will be soon. At the moment the core is cross-compiled from the Java-Client using j2obc, hence the underlying repo is the java one. We are in the process of evaluating how well this worked.
:D I am actually trying to do something similar with the js client. I recently tried to convert it to Dart using jsparser, since i am working with http://flutter.io, a hybrid app development project from Google. It worked out just fine for now, currently testing it to get the weak spots fixed.
