Render realtime RethinkDB results in React

https://github.com/mikemintz/react-rethinkdb

by g4k • 11 years ago

99 39 11 years ago

github.com

jokull• 11 years ago

I guess this is intended for trusted clients?

allendoerfer• 11 years ago

Is there such a thing? ;-)

This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/exa...

toomim• 11 years 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.

escherize3• 11 years 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

swah• 11 years ago

Are you writing big projects with this combination?

escherize3• 11 years 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• 11 years ago

What other technologies do you use alongside reagent?

Also, have you every tried re-frame?

escherize3• 11 years 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/

applecore• 11 years ago

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

veb• 11 years 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.

jsprogrammer2• 11 years 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• 11 years ago

Perhaps they are making something they themselves will use? Look at everyone hopping on the database bandwagon!

jbhatab• 11 years ago

Show me a tool out there that already does this in react. Besides relay, which isn't released, I don't know of one. Defining data in your component is a new concept to the entire javascript and web development world. I view this more as innovative than jumping on a bandwagon.

andrewingram• 11 years ago

I've been using React for a year and a half, and it's probably the first thing in the JavaScript ecosystem for a long time (maybe since jQuery) that hasn't made me regret building a project using it.

It's not without its issues, but it's really changed the way I build things, which after 18 years is kind of impressive.

nperez• 11 years ago

Before I jump to conclusions, can I ask what your experience level with React is like?

I think a lot of people make snap responses to the subject of new developments in the JS world because they see a lot of change happening, do not trust any of it, but also haven't bothered to further their education on the subject.

I'm curious to hear comments from those who are very knowledgable on React but also view it as a bandwagon.

crucialfelix2• 11 years 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• 11 years 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.

crucialfelix2• 11 years 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• 11 years ago

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

Gigablah• 11 years ago

Now that you've gotten the Reddit out of your system, how do you really feel about this project?

tinco3• 11 years ago

I've got a toy RethinkDB+React stack too, here's an example application: 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)

151555• 11 years 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• 11 years 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.

tinco3• 11 years ago

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style.

That they never will has more to do with the general attitude of Rails programmers, and their commitment to the REST request/response model. Libraries that offer more flexible interactions are simply not very visible yet.

Slightly related but not relevant now, Ruby 3.0 is expected to have some concurrency construct fundamentally integrated into the language.

curiousjorge2• 11 years 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!

imslavko3• 11 years 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.

curiousjorge2• 11 years 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?

imslavko3• 11 years ago

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.

mikemintz2• 11 years 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.

Render realtime RethinkDB results in React

Related Stories