Live data from Hacker News

Advancing the realtime web

rethinkdb.com

21–30 of 51 posts

Re: Advancing the realtime web

#21
post #20

I wonder if it would be feasible to add this sort of real-time feed to a conventional RDBMS like PostgreSQL. This feature would be quite useful for at least one of my projects, but I'm not sure I want to give up a mature SQL-based DBMS for something relatively unproven like RethinkDB.

Postgres supports LISTEN / NOTIFY [1,2], and you can stream a SELECT using COPY or a cursor. 1. http://www.postgresql.org/docs/9.4/static/sql-listen.html 2. http://www.postgresql.org/docs/9.4/static/sql-notify.html

Also a brief tutorial on how it works. See in particular the comment by Max Martinsson on how to do it in a replicated scenario.

https://www.chrisstucchio.com/blog/2013/postgres_external_tr...

Re: Advancing the realtime web

#22

The article discusses how RethinkDB differs from "realtime sync services" such as Pusher, PubNub, and Firebase. While comparing against Firebase makes sense because it's an alternative database, I see Pusher and PubNub (and similar pubsub services, such as Fanout) as being complementary to RethinkDB.

This is tricky because PubNub recently added some data storage capabilities, and Pusher and fanout might follow suit. Also, being able to get a feed on queries might ultimately make services like Pusher unnecessary in many traditional situations, but this isn't immediately obvious. We'll find out soon how this develops!

I can speak for Fanout and say that we have no intention of offering data storage. Our ideal users either have databases already or value a decoupled backend architecture.

BaaS is certainly a tempting business (just look at all the exits), but we'd rather focus on doing one thing really well and with wider applicability. Much like you guys, really.

Re: Advancing the realtime web

#23

The article discusses how RethinkDB differs from "realtime sync services" such as Pusher, PubNub, and Firebase. While comparing against Firebase makes sense because it's an alternative database, I see Pusher and PubNub (and similar pubsub services, such as Fanout) as being complementary to RethinkDB.

Article also points out that you can't get a "realtime incremental feed", but the example they provide is quite easy and similar in Firebase by using orderBy() and limit() to return an updating query.

As someone who has built lots of apps using Firebase, I can appreciate the first point about limited querying capabilities; this has been my number 1 painpoint from Firebase. I'd imagine the second point can be somewhat validated by changes() allowing for much more complex queries than are currently possible with sync services.

Re: Advancing the realtime web

#24

The article discusses how RethinkDB differs from "realtime sync services" such as Pusher, PubNub, and Firebase. While comparing against Firebase makes sense because it's an alternative database, I see Pusher and PubNub (and similar pubsub services, such as Fanout) as being complementary to RethinkDB.

agree

and also GO FANOUT

Re: Advancing the realtime web

#26
post #20

I wonder if it would be feasible to add this sort of real-time feed to a conventional RDBMS like PostgreSQL. This feature would be quite useful for at least one of my projects, but I'm not sure I want to give up a mature SQL-based DBMS for something relatively unproven like RethinkDB.

Postgres supports LISTEN / NOTIFY [1,2], and you can stream a SELECT using COPY or a cursor. 1. http://www.postgresql.org/docs/9.4/static/sql-listen.html 2. http://www.postgresql.org/docs/9.4/static/sql-notify.html

LISTEN / NOTIFY is not recommended for production use. It will consume all of your connection pools gradually.

Re: Advancing the realtime web

#27
post #26
post #20

Earlier quoted context omitted.

Postgres supports LISTEN / NOTIFY [1,2], and you can stream a SELECT using COPY or a cursor. 1. http://www.postgresql.org/docs/9.4/static/sql-listen.html 2. http://www.postgresql.org/docs/9.4/static/sql-notify.html

LISTEN / NOTIFY is not recommended for production use. It will consume all of your connection pools gradually.

I can see how that could happen depending on how it is used, but I don't see how that must happen. Can you elaborate?

Re: Advancing the realtime web

#28
On the one hand this is pretty awesome - just as I expect from the rethinkdb team - but on the other hand I'm wondering that while they are removing serious pain points from web development where are the startups that use these as a competitive advantage? Is RethinkDB understood?

Re: Advancing the realtime web

#29
post #12
post #10

Could someone elaborate on the use-cases that rethinkdb tries to solve? As a DB newb, what are the advantages of rethinkdb vs. other NoSQL DBs like Mongo. Why and where would I use rethink instead of an SQL DB like postgres?

Just three reasons among others: 1. Joins (real server-side joins) - so you can have many-to-many relations in your data (and nested arrays are a poor answer to this problem) 2. Awesome query language - No strings to concatenate, no strings to escape, no JSON objects with special keys, just plain JavaScript/Python/Ruby/etc. 3. Schemaless - Faster to prototype things, to adapt to a third party data changing.

PostgreSQL can be schemaless if you want it to be. It obviously does joins, so that leaves only the awesome query language.

Re: Advancing the realtime web

#30
I'm working on an open source firebase-like database that puts realtime/sync/replication/master-master/p2p at its core, rather than an after thought which a lot of other databases (MySQL, MongoDB, etc.) do. The RethinkDB guys are smart and I'm glad they are pushing in this direction, it is important. My project is at http://github.com/amark/gun if anybody is interested.
Post reply on HN