Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advancing the realtime web

rethinkdb.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Advancing the realtime web

#31

Post by Lazare »

marknadal wrote: post #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.

How does your project differ from CouchDB? I mean, if there's one database that puts sync, realtime change feeds, and master-master replication at its core, it's CouchDB (and Pouch, Touch, etc.). It would certainly be my first choice for doing anything "firebase-like". What does gun do (or plan to do) different/better?

(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.)

Re: Advancing the realtime web

#32

Post by marknadal »

Lazare wrote: post #31
marknadal wrote: post #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.

How does your project differ from CouchDB? I mean, if there's one database that puts sync, realtime change feeds, and master-master replication at its core, it's CouchDB (and Pouch, Touch, etc.). It would certainly be my first choice for doing anything "firebase-like". What does gun do (or plan to do) different/better? (I mean, nothing wrong with a project that duplicates others, but it seems odd to focus on master-m…

Yeah, great question and good points.

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.

3. GUN is not stable/production ready yet, and it is javascript only currently. Which is pretty limiting as of now, but that will change later.

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?

Re: Advancing the realtime web

#33

Post by abluecloud »

coffeemug wrote: post #3
jwatte wrote: post #2

The article talks about mobile app feeds, and I understand how I could build a system rpc server for mobile and desktop apps. How would this work for web apps? The headline says "real-time web!" 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-...

The basic architecture is browser web server database. 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.

Is this not already possible with MongoDB, using something like mongooses post('save') [1]?

[1] http://mongoosejs.com/docs/middleware.html

Re: Advancing the realtime web

#34

Post by leggetter »

jkarneges wrote: post #14

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 definitely correct. The article focuses more on data synchronisation where as a lot of services (some of which jkarneges has highlighted) don't offer data storage and focus on letting you define your own feeds/channels/topics/subjects and exposing data updates/changes via messages or events. These services are highly complementary to RethinkDB as it's very easy to see how a channel subscription can map to a changefeeds.

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.

Re: Advancing the realtime web

#35

Post by amelius »

I assume RethinkDB allows the direct use of the database from within the client.

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)?

Re: Advancing the realtime web

#36

Post by Lazare »

marknadal wrote: post #32
Lazare wrote: post #31

Earlier quoted context omitted.

How does your project differ from CouchDB? I mean, if there's one database that puts sync, realtime change feeds, and master-master replication at its core, it's CouchDB (and Pouch, Touch, etc.). It would certainly be my first choice for doing anything "firebase-like". What does gun do (or plan to do) different/better? (I mean, nothing wrong with a project that duplicates others, but it seems odd to focus on master-m…

Yeah, great question and good points. 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. 3. GUN is n…

No, that does clarify things. Being a graph database is a big difference; CouchDB is strictly document based.

(Incidentally, you might want to checkout PouchDB, if you haven't already. It's a javascript implementation of CouchDB, and it runs quite well on Node, and can use LevelDB or any LevelDOWN compatible datastore, which makes it pretty useful as a lightweight embedded DB. Again though, documents only.)

Re: Advancing the realtime web

#37

Post by Already__Taken »

amelius wrote: post #35

I assume RethinkDB allows the direct use of the database from within the client. 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)?

You assume wrong, the post talks about the possibility of the developers including a proxy to secure client requests to the database.

Re: Advancing the realtime web

#38

Post by amelius »

Already__Taken wrote: post #37
amelius wrote: post #35

I assume RethinkDB allows the direct use of the database from within the client. 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)?

You assume wrong, the post talks about the possibility of the developers including a proxy to secure client requests to the database.

Indeed, thanks for correcting.

Re: Advancing the realtime web

#40

Post by agrothberg »

The post says: >We'd like to make more complex queries available via realtime push. In particular, efficient realtime push implementations for the eq_join command and map/reduce are fairly complex, and aren't making it into 1.16.

Will innerJoin be supported in 1.16?

Post reply on HN