6 ms·

Render realtime RethinkDB results in React

99 points by g4k 11y ago

jokull 11y ago
I guess this is intended for trusted clients?
- allendoerfer 11y ago
  Is there such a thing? ;-) This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/examples/chat/server/AuthManager.js https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
  - toomim 11y ago
    I think the issue is that the client code is running actual database queries on the server, and I don't see any restrictions on what queries can be executed. So if you log in and authenticate (through that file), it seems like you can just open the javascript console in chrome and run any type of db query you want.
    - mikemintz 11y ago
      DB queries are validated through a whitelist on the server, so it should be impossible to run an unauthorized query when it's locked down. E.g. https://github.com/mikemintz/react-rethinkdb/blob/master/examples/chat/server/queries.js https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
    - deleted 11y ago
      [deleted]
escherize 11y ago
I am excited about rethink and I use react (via cljs + reagent [1]) every day. The FRP approach of reagent combined with subscribing to rethink for updates is very appealing. [1] http://reagent-project.github.io http://reagent-project.github.io
- swah 11y ago
  Are you writing big projects with this combination?
  - escherize 11y ago
    Our project has 2.5k loc. You can checkout our staging server at staging.fetchh.io/app if you'd like to poke around
- KurtMueller 11y ago
  What other technologies do you use alongside reagent? Also, have you every tried re-frame?
  - escherize 11y ago
    Yeah, we use re-frame[1]. It's fantastic. I'd say if someone does frontend development at all they should totally read the readme.md for it.[1] Being able to file away state changes that don't matter in an FRP way has just been an amazing win for our app. [1] https://github.com/Day8/re-frame/ https://github.com/Day8/re-frame/
applecore 11y ago
Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.
- deleted 11y ago
  [deleted]
  - scrollaway 11y ago
    React-Europe ended yesterday. It probably got some people excited.
- veb 11y ago
  I'm not sure that grabbing yourself a slice of the hype-pie is necessarily a bad thing. Learning is good for the soul, right? I do get your point, if you had one. It does feel like there's a must-have new shiny thing to prod every other day. However, React seems to be even shinier than others as of late -- I know this because I even read the documentation and played with the tutorial! I do admit that I can't really come to any solid conclusions about how shiny React realistically is because I'm not much of a sample size. I do find the React docs to be excellent though which means I'm more likely to keep playing with it. Nothing turns me off faster than awful documentation.
  - deleted 11y ago
    [deleted]
  - jsprogrammer 11y ago
    React is so shiny that it sucks your entire application (HTML and CSS included) up into it's non-standard JavaScriptified web-page format.
- woah 11y ago
  Perhaps they are making something they themselves will use? Look at everyone hopping on the database bandwagon!
- jbhatab 11y ago
crucialfelix 11y ago
Interesting approach. I would still rather connect to RethinkDB with a frontend service and push those to stores and have the component watch the store. Because while this might work for a small use case, a real world usage will quickly outgrow that and you will wish you hadn't stuffed such functionality in a display component. So this is probably most useful for quick sketches and debugging stuff.
- zachallaun 11y ago
  Could you elaborate on this? This project seems to be moving in the same direction the React team is with Relay and GraphQL – the component describes the query it requires to render itself, and a query/caching layer executes the query automatically.
  - crucialfelix 11y ago
    What I described as a Service would be what this query/caching layer is. I would just rather not have it embedded in the Component, making it harder to follow what a Component does. The beauty of them is that they are simple to read and understand. The more mixins you use, the more esoteric it gets and you have to read a bunch of code to understand why the render function magically has these properties to display with. Another point would be that the service or store could be re-used in more than just react, and it can be tested without having to consider the UI.
brohipsterdev2 11y ago
Holy "shiny new tech buzzword compliance" batman! This is hipster dev certified!
- Gigablah 11y ago
  Now that you've gotten the Reddit out of your system, how do you really feel about this project?
  - devtardssuck 11y ago
    I am guessing he feels like the hype hipsters who pump and dump their turds onto gitflub should be called out.
tinco 11y ago
I've got a toy RethinkDB+React stack too, here's an example application: https://github.com/tinco/celluloid-rethinkdb-chat https://github.com/tinco/celluloid-rethinkdb-chat It's Ruby+Celluloid doing subscriptions on RethinkDB, and it uses Meteor's DDP protocol to talk to the React client side. Was pretty easy to build. All the modern technologies fit really well together. Unfortunately in the Ruby world live webservices like this haven't really taken off much yet, so I had to write some low-ish level things myself (The DDP server implementation, which I think is the only non-Meteor DDP server implementation out there, and the celluloid-websocket implementation, which was easy because there's a great ruby websocket library by the faye people)
- 15155 11y ago
  > Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.
  - andrewmutz 11y ago
    The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven model, there are good options for most languages.
    - 15155 11y ago
      It has everything to do with Ruby. With Go, Node.js, Erlang/Elixir, you don't enter the stage assuming that every operation you do is actually going to block others. Concurrency is not a first-class concept in Ruby (nor Python). Yes, EventMachine exists. Ok, it's not the standard nor norm, and I would wager most Ruby programmers have heard of it but haven't actually used it. Even if you're using EventMachine or Twisted, those technologies are infectious (by necessity, not complaining here)- everything you build or use needs to utilize those primitives to work successfully. In Node.js, the assumption is that nothing will block a calling thread (in favor of asynchronous callbacks). In Go, the assumption is that goroutines (via a semi-preemptive scheduler) will not block their caller. In Erlang, the assumption is that processes will not block one another (with a fully preemptive scheduler). As a fan of Node.js- I will state, not having a widely-accepted, standard interface for building concurrent programs (vs. the soup of callbacks/Promises, associated async/await implementations, coroutines via generator functions) has been a severe detriment to the community.
curiousjorge 11y ago
> 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!
- imslavko 11y ago
  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.
  - curiousjorge 11y ago
    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?
    - imslavko 11y ago
      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.
imslavko 11y ago
I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb 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/4307 - https://github.com/rethinkdb/rethinkdb/issues/2727 https://github.com/rethinkdb/rethinkdb/issues/2727 Something you might want to consider when you decide to implement it.
- mikemintz 11y ago
  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.

99 points by g4k 11y ago

jokull 11y ago

I guess this is intended for trusted clients?

allendoerfer 11y ago
Is there such a thing? ;-) This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/examples/chat/server/AuthManager.js https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
- toomim 11y ago
  I think the issue is that the client code is running actual database queries on the server, and I don't see any restrictions on what queries can be executed. So if you log in and authenticate (through that file), it seems like you can just open the javascript console in chrome and run any type of db query you want.
  - mikemintz 11y ago
    DB queries are validated through a whitelist on the server, so it should be impossible to run an unauthorized query when it's locked down. E.g. https://github.com/mikemintz/react-rethinkdb/blob/master/examples/chat/server/queries.js https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
  - deleted 11y ago
    [deleted]

escherize 11y ago

I am excited about rethink and I use react (via cljs + reagent [1]) every day. The FRP approach of reagent combined with subscribing to rethink for updates is very appealing. [1] http://reagent-project.github.io http://reagent-project.github.io

swah 11y ago
Are you writing big projects with this combination?
- escherize 11y ago
  Our project has 2.5k loc. You can checkout our staging server at staging.fetchh.io/app if you'd like to poke around
KurtMueller 11y ago
What other technologies do you use alongside reagent? Also, have you every tried re-frame?
- escherize 11y ago
  Yeah, we use re-frame[1]. It's fantastic. I'd say if someone does frontend development at all they should totally read the readme.md for it.[1] Being able to file away state changes that don't matter in an FRP way has just been an amazing win for our app. [1] https://github.com/Day8/re-frame/ https://github.com/Day8/re-frame/

applecore 11y ago

Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.

deleted 11y ago
[deleted]
- scrollaway 11y ago
  React-Europe ended yesterday. It probably got some people excited.
veb 11y ago
I'm not sure that grabbing yourself a slice of the hype-pie is necessarily a bad thing. Learning is good for the soul, right? I do get your point, if you had one. It does feel like there's a must-have new shiny thing to prod every other day. However, React seems to be even shinier than others as of late -- I know this because I even read the documentation and played with the tutorial! I do admit that I can't really come to any solid conclusions about how shiny React realistically is because I'm not much of a sample size. I do find the React docs to be excellent though which means I'm more likely to keep playing with it. Nothing turns me off faster than awful documentation.
- deleted 11y ago
  [deleted]
- jsprogrammer 11y ago
  React is so shiny that it sucks your entire application (HTML and CSS included) up into it's non-standard JavaScriptified web-page format.
woah 11y ago
Perhaps they are making something they themselves will use? Look at everyone hopping on the database bandwagon!
jbhatab 11y ago

crucialfelix 11y ago

Interesting approach. I would still rather connect to RethinkDB with a frontend service and push those to stores and have the component watch the store. Because while this might work for a small use case, a real world usage will quickly outgrow that and you will wish you hadn't stuffed such functionality in a display component. So this is probably most useful for quick sketches and debugging stuff.

zachallaun 11y ago
Could you elaborate on this? This project seems to be moving in the same direction the React team is with Relay and GraphQL – the component describes the query it requires to render itself, and a query/caching layer executes the query automatically.
- crucialfelix 11y ago
  What I described as a Service would be what this query/caching layer is. I would just rather not have it embedded in the Component, making it harder to follow what a Component does. The beauty of them is that they are simple to read and understand. The more mixins you use, the more esoteric it gets and you have to read a bunch of code to understand why the render function magically has these properties to display with. Another point would be that the service or store could be re-used in more than just react, and it can be tested without having to consider the UI.

brohipsterdev2 11y ago

Holy "shiny new tech buzzword compliance" batman! This is hipster dev certified!

Gigablah 11y ago
Now that you've gotten the Reddit out of your system, how do you really feel about this project?
- devtardssuck 11y ago
  I am guessing he feels like the hype hipsters who pump and dump their turds onto gitflub should be called out.

tinco 11y ago

I've got a toy RethinkDB+React stack too, here's an example application: https://github.com/tinco/celluloid-rethinkdb-chat https://github.com/tinco/celluloid-rethinkdb-chat It's Ruby+Celluloid doing subscriptions on RethinkDB, and it uses Meteor's DDP protocol to talk to the React client side. Was pretty easy to build. All the modern technologies fit really well together. Unfortunately in the Ruby world live webservices like this haven't really taken off much yet, so I had to write some low-ish level things myself (The DDP server implementation, which I think is the only non-Meteor DDP server implementation out there, and the celluloid-websocket implementation, which was easy because there's a great ruby websocket library by the faye people)

15155 11y ago
> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.
- andrewmutz 11y ago
  The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven model, there are good options for most languages.
  - 15155 11y ago
    It has everything to do with Ruby. With Go, Node.js, Erlang/Elixir, you don't enter the stage assuming that every operation you do is actually going to block others. Concurrency is not a first-class concept in Ruby (nor Python). Yes, EventMachine exists. Ok, it's not the standard nor norm, and I would wager most Ruby programmers have heard of it but haven't actually used it. Even if you're using EventMachine or Twisted, those technologies are infectious (by necessity, not complaining here)- everything you build or use needs to utilize those primitives to work successfully. In Node.js, the assumption is that nothing will block a calling thread (in favor of asynchronous callbacks). In Go, the assumption is that goroutines (via a semi-preemptive scheduler) will not block their caller. In Erlang, the assumption is that processes will not block one another (with a fully preemptive scheduler). As a fan of Node.js- I will state, not having a widely-accepted, standard interface for building concurrent programs (vs. the soup of callbacks/Promises, associated async/await implementations, coroutines via generator functions) has been a severe detriment to the community.

curiousjorge 11y ago

> 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!

imslavko 11y ago
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.
- curiousjorge 11y ago
  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?
  - imslavko 11y ago
    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.

imslavko 11y ago

I've built a RethinkDB-Meteor integration using ReQLite and Meteor's stack: (https://github.com/Slava/meteor-rethinkdb 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/4307 - https://github.com/rethinkdb/rethinkdb/issues/2727 https://github.com/rethinkdb/rethinkdb/issues/2727 Something you might want to consider when you decide to implement it.

mikemintz 11y ago
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.