Fork me on GitHub
#re-frame
<
2015-09-04
>
seantempesta05:09:16

@danielcompton @mikethompson: So the idea is to use a dynamic subscriptions to request change streams from rethinkdb over a sente connection? Would the data be loaded in the app-db or just available directly from the subscription?

mikethompson07:09:04

@seantempesta: that's an area of active discussion for us. There's (at least) three possible models: 1. Pure model: regard a rethinkdb instance as a complete replacement for app-db. Your views can subscribe to change feeds (from rethinkdb) and your event handlers can issue modification (queries) to rethinkdb. 2. Hybrid solution: where some ephemeral state is held in app-db and some is persisted state is in rethinkdb. When a view subscribes to data, it actually doesn't know where it is coming from ... the subscription handers know if it comes from rethinkdb or app-db. 3. app-db as a mirror/buffer: any data obtained from rethinkdb is put into app-db. views subscribe from app-db. etc.

mikethompson07:09:54

Note: because of the nature of our apps, we are going with thin servers and thick clients. Clients have a lot of responsibility. That's definitely not an approach that everyone might feel comfortable with.

seantempesta07:09:45

Yeah. I’ve been thinking about how to do it and think #3 might be best. It allows you to keep the benefits of re-frame’s signal graph and enables straightforward caching of entities (kind of like relay?). What’s your opinion?

mikethompson07:09:29

Distributed state and the syncing of it, is the root of all evil.

mikethompson07:09:40

So #3 has some downsides

mikethompson07:09:58

But we're still experiementing

seantempesta07:09:14

Do you guys have any examples of using rethinkdb’s .changes() with clojure? I didn’t see it documented in clj-rethinkdb.

mikethompson07:09:57

Daniel might be able to help, but in the meantime have a look in the clj-rethinkdb tests

seantempesta07:09:07

oh yeah, good idea

mikethompson07:09:42

Just to be clear, our solution (which will absolutely not suit everyone), is to: 1. Have clients construct queries (<--- shock, horror) 2. Ship those queries (which are just data, thanks rethinkdb) down a websocket 3. Have a proxy server sitting in front of rethinkdb, which establishes the websockets. And which looks after security. And which issues the arriving queries to rethinkdb, then shuffles answers back to clients (websockets).

mikethompson07:09:32

The proxy is thin

seantempesta07:09:37

oh yeah, I’m down with that plan. I am stoked to get something like this working.

seantempesta07:09:08

Any thoughts on how you’re going to do the security in the proxy?

mikethompson07:09:10

Because of the nature of our apps, we can do a lot via IP whitelisting (remember we use websockets). But apart from that, i would have thought that json web tokens would be the next best

mikethompson07:09:44

BUT I'm not very savy in the area

seantempesta07:09:11

oh, not so much the authentication, but the authorization part. Like how do you ensure the user is allowed to issue the query.

seantempesta07:09:34

fwiw I’m also do jwt

seantempesta07:09:23

it seems like the only downside to using web tokens is revoking access and I think that can be solved by listening for changes to the user entity in rethinkdb

mikethompson07:09:51

Yeah, the nature of our app means there's a bunch of security issues we don't have to worry about.

mikethompson07:09:41

One thing to keep in mind .... when a query arrives at the server, it is data. (thanks rethinkdb).

seantempesta07:09:58

Yeah…so it can be parsed and evaluated.

mikethompson07:09:07

That data can be inspected, matched against patterns, etc

seantempesta07:09:29

Okay. This is great. Thanks mike.

mikethompson07:09:43

No problem. I wish we had more that we could share

seantempesta07:09:19

Oh no worries. It’s nice to know that my thoughts were pretty similar.

paulspencerwilliams07:09:36

Oops, accidentally deleted my post on the train rather than updating it..

paulspencerwilliams07:09:13

So, it looks like my events are working, but actually, its the subscriptions that don’t appear wired up correctly.

mikethompson07:09:56

@paulspencerwilliams: I can, indeed, only see this one post. Not much information simple_smile

paulspencerwilliams17:09:16

Question about idioms… If I have a form with two input boxes and a save button, would you typically create components for each control, or a single component for the form: I presume the former. In this case, would you have text values in app-state for each text input updated on input change, and the commit would raise a :save-event updating a composite value in app-state based on the two input values?

mikethompson21:09:05

Yes, I'd create components for each control (name and address?) and associated with each, I'd have a (dispatch [:name XXX]) and (dispatch [:address XXX]) and I'd also have a (dispatch [:save-clicked]) attached to that button. Having said that, my apps don't tend to be very form-ish. So we should wait to hear if others chime in here with their best practice.