Live data from Hacker News

DeepstreamHub: a faster Firebase with an open core

deepstreamhub.com

31–40 of 45 posts

Re: DeepstreamHub: a faster Firebase with an open core

#31
I don't see any benchmarks showing this as "faster." Seems like a pretty serious claim.

From the Firebase JavaScript SDK, I can do one thousand individual gets with a 3.4k payload at 1-2ms each. http://jsfiddle.net/katowulf/8wkon62c/

Mileage varies, of course, but I'd love to see a benchmark I can run side by side that can beat those numbers. I can't even get close with a simple GET, which returns in 86ms.

Re: DeepstreamHub: a faster Firebase with an open core

#32
post #25

Not exactly Firebase in that it doesn't provide an arbitrarily nested JSON structure as a datastore but more of a document-based approach. Overall a pretty good alternative to Firebase but there is no security rules, no default data store or auth so you need a lot more work. Lists are not very good being just a record with an array of record keys and not the actual data. I use the self-hosted version (deepstream.io)…

We switched from firebase to deepstream, and are hosting it ourselves.

With firebase since we were not running a node or java app, we ended up relying heavily on the rest interface. Which was sort of the not well taken care of. We would see crazy spikes and we could not get support to fix it. Multi tenancy would occasionally cause other performance issues.

We eneded up running a bit of a monkey patched system for awhile using kineses to pipe updates to a java/node app which then would write updates via the web socket interface.

Firebase also lacked support for pub/sub events, which can be sort of faked, but not entirely reliably.

Deepstream model is a bit different as you said, and it does have some weaknesses. I have submitted a number of patches already to fix some of the edge cases i've run into and will likely submit more.

Unlike firebase, we can actually directly improve the deepstream application core as well as build options into the platform that better support our use cases.

Re: DeepstreamHub: a faster Firebase with an open core

#33
post #24
post #9

Earlier quoted context omitted.

Give it some time.

Can you provide more information regarding this reply? My opinion is if a service goes dark, I probably shouldn't consider using it.

Recently we had a meeting about the next phase of the project now that Horizon and RethinkDB are owned by the linux foundation: https://www.youtube.com/watch?v=EG0aucGzJE8&t=279s

Re: DeepstreamHub: a faster Firebase with an open core

#34
post #25

Not exactly Firebase in that it doesn't provide an arbitrarily nested JSON structure as a datastore but more of a document-based approach. Overall a pretty good alternative to Firebase but there is no security rules, no default data store or auth so you need a lot more work. Lists are not very good being just a record with an array of record keys and not the actual data. I use the self-hosted version (deepstream.io)…

Deepstreamhub member here: The platform, similar to Firebase supports multiple Auth strategies and has a fine grained permission language called Valve, similar to Firebase's Bolt. Please find an overview of security concepts here https://deepstreamhub.com/tutorials/guides/security-overview...

Dsh allows you to store arbitrary data, but breaks it down into smaller chunks a large Mongo or Couch db.

As these smaller chunks have their own life cycle lists make it easy to use them within iterators, e.g. For each in Vue etc, where every component manages bits own granular document

Re: DeepstreamHub: a faster Firebase with an open core

#35

Earlier quoted context omitted.

They're quite different. In particular, the Realm Mobile Platform is built on a full-blown database running on the user's device. One of Realm's biggest selling points is offline-first applications. As far as I can tell, this is not the case with Deepstream.

Just to build on what mwcampbell said (and in full disclosure, I'm on the team at Realm). Architecturally, Realm and DeepstreamHub are quite different. Realm at its core is a distributed object database that updates changes to objects in realtime. DeepstreamHub, as far as I can tell, relies on a pub/sub and request/response architecture. They are two fundamentally different approaches to the challenge of realtime. On…

Actually, deepstream has a very similar datasync approach with its records, pub sub and rpcs are mainly a supporting feature.

Re: DeepstreamHub: a faster Firebase with an open core

#36

I don't see any benchmarks showing this as "faster." Seems like a pretty serious claim. From the Firebase JavaScript SDK, I can do one thousand individual gets with a 3.4k payload at 1-2ms each. http://jsfiddle.net/katowulf/8wkon62c/ Mileage varies, of course, but I'd love to see a benchmark I can run side by side that can beat those numbers. I can't even get close with a simple GET, which returns in 86ms.

Here you go: https://deepstream.io/info/performance/single-node-vs-cluste...

Re: DeepstreamHub: a faster Firebase with an open core

#38

Earlier quoted context omitted.

They're quite different. In particular, the Realm Mobile Platform is built on a full-blown database running on the user's device. One of Realm's biggest selling points is offline-first applications. As far as I can tell, this is not the case with Deepstream.

Just to build on what mwcampbell said (and in full disclosure, I'm on the team at Realm). Architecturally, Realm and DeepstreamHub are quite different. Realm at its core is a distributed object database that updates changes to objects in realtime. DeepstreamHub, as far as I can tell, relies on a pub/sub and request/response architecture. They are two fundamentally different approaches to the challenge of realtime. On…

Thanks for the explanation. I should try out both with this understanding to see which approach is more suitable for different situations.

Re: DeepstreamHub: a faster Firebase with an open core

#39

I don't see any benchmarks showing this as "faster." Seems like a pretty serious claim. From the Firebase JavaScript SDK, I can do one thousand individual gets with a 3.4k payload at 1-2ms each. http://jsfiddle.net/katowulf/8wkon62c/ Mileage varies, of course, but I'd love to see a benchmark I can run side by side that can beat those numbers. I can't even get close with a simple GET, which returns in 86ms.

also: https://deepstream.io/info/performance/four-billion-messages...

direct benchmarks are something that Firebase' Terms and Conditions make hard to do

Re: DeepstreamHub: a faster Firebase with an open core

#40

I don't see any benchmarks showing this as "faster." Seems like a pretty serious claim. From the Firebase JavaScript SDK, I can do one thousand individual gets with a 3.4k payload at 1-2ms each. http://jsfiddle.net/katowulf/8wkon62c/ Mileage varies, of course, but I'd love to see a benchmark I can run side by side that can beat those numbers. I can't even get close with a simple GET, which returns in 86ms.

also: https://deepstream.io/info/performance/four-billion-messages... direct benchmarks are something that Firebase' Terms and Conditions make hard to do

Benches just aren't meant for this type of analysis.

Two different engines doing two different things.

Benches are for recording "personal best" stats, not "laps at the public pool". I.e. Testing against self and not others.

Post reply on HN