This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-14
Channels
- # admin-announcements (1)
- # beginners (18)
- # boot (61)
- # cljsjs (4)
- # cljsrn (12)
- # clojure (60)
- # clojure-gamedev (1)
- # clojure-russia (13)
- # clojure-taiwan (1)
- # clojure-uk (4)
- # clojurescript (62)
- # core-async (7)
- # cursive (1)
- # data-science (1)
- # hoplon (74)
- # lein-figwheel (3)
- # off-topic (3)
- # om (2)
- # other-languages (58)
- # planck (4)
- # protorepl (3)
- # reagent (58)
- # rethinkdb (1)
- # spacemacs (1)
Hello! I made my hoplon page use castra to ask server to fetch a third party db. Could it be faster if the server could fetch db when the page is requested (before hoplon client even ask) and push it asynchroniously to hoplon when ready? If so how would you do it??? Thanks!
Oh... hoplon/notify...
@jumblerg: I read this in slack log "jumblerg 03:06:40 i do, however, have a branch of castra i’m hacking for the purpose of supporting “push", if that’s what you’re looking for"
I would be interested in trying that out. Where can I find this? Do you have a minimal example? Much thanks in advance !
Found this. https://github.com/hoplon/castra/commit/ac0844da182794ef774c6bf0b0e2cc23c7ebc317 Sadly I don't understand hownto use state-fn .. :-(
@jumberg Can it speed up initial data loading from db to client?
See above
I have tried to put (.popup (js/jQuery elem))
into with-init!
or with-dom
or just on itself but the issue persists
@piotrek: what if you use this?
@leontalbot: I will try it, thanks
@leontalbot: it worked! yey!
@piotrek really cool!!
We love cljsjs
@leontalbot: the state-fn pr (which @micha assures me he’s going to review and merge in alongside @raywillig`s someday) is a step towards “push"
yes...
(wrap-castra {:state-fn #(q/model *db*)} ‘myapp.service.command ‘myapp.service.query)
where the model fn returns whatever data the client needs in the request, alongside the result of the function that was explicitly called from the client
the state function becomes the target for any short polling, long polling, http streaming combination that takes place to create the effect of “push”, hence the quotes
the idea is to further separate/segregate the command and query sides of the application such that commands can be called from castra and return their own results (may be nil in most cases), while the state-fn can return whatever data is needed by the application model to create the effect of a binding between the client’s data model in the cell and the data/db on the server.
the state function won’t speed anything up on its own, but it will create a significant optimization if it takes advantage of versioned data: requests to the state-fn should include an as-of parameter so that it will only return those facts that have been written to the database since the client last requested or subscribed to the dataset of interest
this assumes the client implements some sort of explicit caching strategy where data accumulates with each request; it can then request only the additional data that was written to the db since its last request instead of reloading all the things every time.
the state-fn also frees you from having to explicitly return the state at the end of each rpc fn
basically, the client calls an rpc fn/command, the result of that call is returned at the same call site, and the application state returned by the state-fn just happens to hitchhike/piggyback along the same http response, but gets placed in the associated cell instead once it makes it to the client.
The client doesn't need to reask for update
you can see the separate :state
and result
appended to the response map here https://github.com/hoplon/castra/blob/ac0844da182794ef774c6bf0b0e2cc23c7ebc317/src/castra/middleware.clj#L121
correct, up to a point, the client will automatically update itself whenever a command is called.
so if command is called by server, server could say get data updates every 5 minutes...
If there is a change push back to client?
not yet, i’ve yet to commit the “push” implementation that makes use of the state-fn so that the client will update without a command being called.
that is a "promise" 😉
yeah, exactly, a “promise”. 6 months from now you can heckle me about it the same way i’m pestering @micha right now.
you should call "deliver" now...
So, for now, the difference between the result and the state is the thing that is implemented, is that right?
the delta?
i’m not sure what your case is so maybe this doesn’t apply, but i can tell you that, in practice, i haven’t really needed the “push” yet, so that’s why it has slipped a bit on my priority list.
State is an atom?
so I a have a state like this
[{:id "1" :text "hello"} {:id "2" :text "world"}]
and it changes to [{:id "1" :text "hello"} {:id "2" :text "my world"}]
what will be the "result?"
the simplest way would be to have the state-fn return the entire thing on the back of each http request
got it!
I am starting to understand why do this
i didn’t quite understand castra (specifically, how it tied into a cqrs architecture when the commands were in the business of returning query results), until he explained to me that, conceptually, this was just an implementation detail that took advantage of the way http works.
i guess the general idea behind the state-fn is to make the http implementation leak a little bit less
Can't hoplon/notify achieve just this (push)
make castra behave more like an mvcqrsish thing would if it the application lived entirely on one side of the wire
but it looks like it could. my goal is to build this capability into castra without any interface changes
Super newbie question: How do I deploy? I've done the "Getting Started" address-book exercise and it works locally. What do I have to put on my server for this to work for users browsing there? (Probably obvious: I don't do much web programming... but I'm a long time Lisper hoping hoplon is the way to do more on the web.)