This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (25)
- # beginners (21)
- # boot (161)
- # cider (12)
- # clojure (92)
- # clojure-art (1)
- # clojure-germany (5)
- # clojure-nl (5)
- # clojure-russia (38)
- # clojure-sweden (1)
- # clojurescript (87)
- # clojutre (2)
- # cursive (9)
- # datascript (1)
- # datomic (22)
- # devops (1)
- # editors (33)
- # events (3)
- # hoplon (19)
- # immutant (7)
- # jobs (2)
- # ldnclj (22)
- # off-topic (41)
- # re-frame (34)
- # reagent (39)
@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?
@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.
app-db as a mirror/buffer: any data obtained from rethinkdb is put into app-db. views subscribe from app-db. etc.
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.
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?
Do you guys have any examples of using rethinkdb’s .changes() with clojure? I didn’t see it documented in clj-rethinkdb.
Daniel might be able to help, but in the meantime have a look in the clj-rethinkdb tests
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).
oh yeah, I’m down with that plan. I am stoked to get something like this working.
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
oh, not so much the authentication, but the authorization part. Like how do you ensure the user is allowed to issue the query.
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
Yeah, the nature of our app means there's a bunch of security issues we don't have to worry about.
One thing to keep in mind .... when a query arrives at the server, it is data. (thanks rethinkdb).
Oops, accidentally deleted my post on the train rather than updating it..
So, it looks like my events are working, but actually, its the subscriptions that don’t appear wired up correctly.
@paulspencerwilliams: I can, indeed, only see this one post. Not much information
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?
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.