I hide all my realtime streams behind a "/realtime" endpoint and watching specific tables for changes couldn't be easier (just the changes command, which produces an infinite sequence).
Generally as simple as: r.db('db').table('table').changes().run(conn) (depending on your language it might look a little different).
Then again I'm pretty sold on RethinkDB so my opinion should probably come with a large-ish grain of salt.
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.
So services Firebase, PubNub Data Sync, Realtime.co cloud storage, the Google Drive Realtime API and Simperium (see: http://www.leggetter.co.uk/real-time-web-technologies-guide/...) are much more in-context to the article.
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.
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.
and also GO FANOUT
(I mean, nothing wrong with a project that duplicates others, but it seems odd to focus on master-master replication without distinguishing yourself from the most popular DB that's already built around that.)
1. GUN is embedded. Meaning there is no "database server/process" to run, it gets included into your app server as a library. This means less configuration and maintenance.
2. GUN is a graph database. Meaning you can have both relational and document structured data. I'm not sure if CouchDB has added this yet, last time I checked (several years ago) it was only NoSQL.
CouchDB, Riak, Cassandra all try to be master-master, which is good. Unfortunately, in my personal experience, they have also been much more complicated to start using. I'm hoping gun will be easier to roll with. If you're already using CouchDB and happy, you probably shouldn't switch.
Any other questions?
Compare this solution to push it all the way through the web stack: http://engineering.imvu.com/2014/12/27/the-real-time-web-in-...
When the web browser connects to the web server, the web server opens a database feed. When the database pushes changes to the web server, the web server pushes them to the browser via socket.io.
Baking feeds into the database should dramatically simplify the amount of required work.
backed by this repo:
The project is a year old... I'm not sure if it's still in progress (seems not) and I'm not sure if the RDB team themselves are pursuing getting together with meteor
This makes me wonder how they handle security.
For example, let's assume that I want to implement a "filesystem" using this database. How would I add rules that allowed the client-side to use only the records it is allowed to use (for instance, if the "filesystem" is configured such that access is limited for certain users)?
If I'm understanding correctly, RethinkDB could be a drop in replacement for mongodb? What are the benefits to this replacement in the context of Meteor?
Firstly, as the app scales, livequery has to work harder and harder. I don't know how good its scalability is at the moment, but I think it would be very hard to approach the scalability of the feeds built into the database.
Secondly, as we build feed support into more and more queries, you'll be able to get functionality unavailable in livequery, which will allow building more sophisticated realtime experiences than currently possible.
We're going to find out how all these components work together in practice in the next few months. I'm really looking forward to that!
As for real reasons:
- ReQL, functional, composable, and declarative, is very nice to use
- (v1.16) Arbitrary query watching with changefeeds
- Ease of sharding/load-balancing
- (v1.16) dynamic server management through queries
- Awesome web admin API
- Actually saving stuff to disk (couldn't resist)
This video on the highlights of rethinkdb is old but still relevant: https://www.youtube.com/watch?x-yt-ts=1422327029&x-yt-cl=848...
Will innerJoin be supported in 1.16?
There is currently no push implementation for joins. That's coming in the next few releases.
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?
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)
3. Schemaless - Faster to prototype things, to adapt to a third party data changing.