Render realtime RethinkDB results in React • Hacker News Board

Re: Render realtime RethinkDB results in React

#41

Post by imslavko » Sun, Jul 05, 2015, 3:36 AM UTC

I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb).

I see that your TODOs list has "Optimistic UI updates", I worked in this direction and figured there are multiple things blocking such architecture in RethinkDB:

- https://github.com/rethinkdb/rethinkdb/issues/4307

- https://github.com/rethinkdb/rethinkdb/issues/2727

Something you might want to consider when you decide to implement it.

Re: Render realtime RethinkDB results in React

#42

Post by imslavko » Sun, Jul 05, 2015, 3:37 AM UTC

curiousjorge wrote: post #32

> This is similar to solutions like Meteor, Parse, and Firebase. Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to. This is a Meteor.js killer right here folks!

I think it explicitly says that it uses the same idea as Meteor's:

> Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to.

Re: Render realtime RethinkDB results in React

#43

Post by mikemintz » Sun, Jul 05, 2015, 5:20 AM UTC

imslavko wrote: post #41

I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: ( https://github.com/Slava/meteor-rethinkdb ). I see that your TODOs list has "Optimistic UI updates", I worked in this direction and figured there are multiple things blocking such architecture in RethinkDB: - https://github.com/rethinkdb/rethinkdb/issues/4307 - https://github.com/rethinkdb/rethinkdb/issues/2727 Something you might want to c…

Hi Slava! Your project was immensely helpful for me to figure out what's possible. Optimistic updating is definitely the biggest and most challenging feature on my roadmap. I figured I'd save it until last so that by the time I start working on it some of those kinks would be figured out :) but I'm going to take a close look at the blocking issues.

Even when those RethinkDB issues get resolved, I still have some conceptual questions understanding how to make arbitrary queries update optimistically. For example, say that I'm subscribed to:

  r.table('proposals').pluck('name')

And I issue the following update:

  r.table('proposals').filter(r.row('votes').eq(0)).delete()

On the client side, because I used the pluck('name') operation in the subscription query, we can't possibly know which rows to optimistically delete since we didn't download the 'votes' field.

Do you know how this issue is addressed in meteor? I'm currently thinking I'll have to limit optimistic updating to queries that follow a simple structure, but I'd love a more general solution.

Re: Render realtime RethinkDB results in React

#44

Post by curiousjorge » Sun, Jul 05, 2015, 5:39 AM UTC

imslavko wrote: post #42

curiousjorge wrote: post #32

> This is similar to solutions like Meteor, Parse, and Firebase. Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to. This is a Meteor.js killer right here folks!

I think it explicitly says that it uses the same idea as Meteor's: > Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to.

I don't think so because in Meteor.js you rely on iron-router and need to painsteakingly define and manage who can do what, and subscribing to new documents coming in the wire?

Re: Render realtime RethinkDB results in React

#45

Post by imslavko » Mon, Jul 06, 2015, 7:31 AM UTC

curiousjorge wrote: post #44

imslavko wrote: post #42

Earlier quoted context omitted.

I think it explicitly says that it uses the same idea as Meteor's: > Rather than writing database queries in the backend and exposing API endpoints to the frontend, these solutions allow the frontend to directly access the data layer (secured by a permission system) using the same query API that backend services have access to.

I don't think so because in Meteor.js you rely on iron-router and need to painsteakingly define and manage who can do what, and subscribing to new documents coming in the wire?

The concept of subscriptions is completely separate from the router you use. At some point you would need to define who can subscribe to what documents, in any system with private data. It is called ACL.