best way to synchronize objects between server and browser
754 views
Skip to first unread message
falcon
Nov 8, 2012, 9:04:33 AM11/8/12
to knock...@googlegroups.com
I'm wondering if there are frameworks or libraries that knockout users use or recommend to synchronize state between server and browsers.
I realize that I could use various node.js websocket libraries or ajax calls to share data changes, but I will also have to do things like handle browser re-connects, write glue code to hook up knockout to these updates, etc.
There are solutions such as meteor, derbyjs, backbone, etc. which do far more than synchronize state. I'm quite happy with using knockout to bind my UI components to my data and really only need a library which is very good at communicating data between server/client, understand that browsers disconnect and might miss updates, etc.
Thanks and look forward to any suggestions.
Denys Khanzhiyev
Nov 8, 2012, 9:38:59 AM11/8/12
to knockoutjs
The answer depends on your application. And your backend.
Sometimes you talk to thirtd party API, sometimes to your own.
For NodeJS I use nowJS(built on top of socket.io library) for example, but it is SPA with upto 100 - 200 clients online.
If It will be more clients I would come to socket.io directly.
But again it depedns on application. If you do not need push notifications from server classical AJAX will do.
And classical AJAX does everybody now.
Sometimes you talk to thirtd party API, sometimes to your own.
For NodeJS I use nowJS(built on top of socket.io library) for example, but it is SPA with upto 100 - 200 clients online.
If It will be more clients I would come to socket.io directly.
But again it depedns on application. If you do not need push notifications from server classical AJAX will do.
And classical AJAX does everybody now.
rektide
Nov 8, 2012, 9:52:33 PM11/8/12
to knock...@googlegroups.com
Any given Publish/Subscribe framework can form a good basis for syndicating out data-model
changes. I tend to think of synchronization as a syndication problem in the best of cases.
Sychronized data has subscribing listeners, waiting for new events telling them of updates.
In KO's case, we just need for subscription messages to trigger model updates in the client.
Faye is a good example of a Publish/Subscribe framework to help get syndication going.
changes. I tend to think of synchronization as a syndication problem in the best of cases.
Sychronized data has subscribing listeners, waiting for new events telling them of updates.
In KO's case, we just need for subscription messages to trigger model updates in the client.
Faye is a good example of a Publish/Subscribe framework to help get syndication going.
falcon
Nov 9, 2012, 10:25:18 AM11/9/12
to knock...@googlegroups.com
Faye looks interesting and I've used socket.io before. The issue is not actually about how to communicate the changes. I'm trying to figure out a good way to keep the server and the client synchronized, specifically when the browser may disconnect and re-connect at anytime.
If the data being shared is not very much, then a full snapshot of server side state can be sent to the browser, problem solved.
If there is a great deal of data on the server, and the browser also has data, then there should be a way to only send updates to the browser which were dropped during the disconnect.
This picture is further complicated by the fact that different browser clients may not have access to view everything on the server.
There are solutions to all these problems, but I'd like to avoid coding them if someone else has already done so :)
lei...@gmail.com
Nov 9, 2012, 11:48:42 AM11/9/12
to knock...@googlegroups.com
This is entirely dependent on your data model and back end.
The first question you must answer is how do you track changes on the server itself? Do you have a global serialization counter? Can you extract a snapshot of your data at any given serialization point? Or, possibly, do you have a log of deltas that can be indexed by serial counter? If the latter, then all you need to do is have the client remember the most recent serial and upon reconnect request all updates since.
The depth to your problem can be enormous, and simply saying use XYZ w/o knowing even what runs your back end is impossible.
There are numerous approaches possible. You could in theory treat the server and each client as a git repo and use a similar (or git itself) mechanism. Just store your latest SHA1 in a cookie, and the data in memory.
Also depends on how much data you expect the client to keep resident. All vs partial are vastly different problems to solve.
The first question you must answer is how do you track changes on the server itself? Do you have a global serialization counter? Can you extract a snapshot of your data at any given serialization point? Or, possibly, do you have a log of deltas that can be indexed by serial counter? If the latter, then all you need to do is have the client remember the most recent serial and upon reconnect request all updates since.
The depth to your problem can be enormous, and simply saying use XYZ w/o knowing even what runs your back end is impossible.
There are numerous approaches possible. You could in theory treat the server and each client as a git repo and use a similar (or git itself) mechanism. Just store your latest SHA1 in a cookie, and the data in memory.
Also depends on how much data you expect the client to keep resident. All vs partial are vastly different problems to solve.
falcon
Nov 9, 2012, 12:02:57 PM11/9/12
to knock...@googlegroups.com, lei...@gmail.com
I was hoping there were several solutions out there and I could pick from among them.
I know there is derbyjs's racer, meteorjs has some synchronization more deeply embedded in their framework. I was hoping there were more such frameworks or libraries.
rektide
Nov 9, 2012, 12:28:37 PM11/9/12
to knock...@googlegroups.com
This is certainly not an easy problem, but I still tend to view it from the same filter:
it's a matter of syndicating out changes. Whether a client is operating in a disconnected
state does not affect whether or not they need, at some point down the road, to receieve all
the published messages on a channels.
As for being complicatd by different clients having different data sources, well, that's the
easiest problem in the world for pub/sub: each model that client does have access to get
it's own channel. If the client hasn't subscribed to a channel, doesn't know about the
channel, they don't get that data.
This is just one way to begin to think about an enormous problem. It doesn't begin to deal
with conflict resolution, or operational transforms (more simply: what the messages being
pub/subbed say, what they instruct a system to do).
In-Reply-To: <f241f01f-adbf-4479...@googlegroups.com>
it's a matter of syndicating out changes. Whether a client is operating in a disconnected
state does not affect whether or not they need, at some point down the road, to receieve all
the published messages on a channels.
As for being complicatd by different clients having different data sources, well, that's the
easiest problem in the world for pub/sub: each model that client does have access to get
it's own channel. If the client hasn't subscribed to a channel, doesn't know about the
channel, they don't get that data.
This is just one way to begin to think about an enormous problem. It doesn't begin to deal
with conflict resolution, or operational transforms (more simply: what the messages being
pub/subbed say, what they instruct a system to do).
In-Reply-To: <f241f01f-adbf-4479...@googlegroups.com>
Matthew Schinckel
Nov 11, 2012, 6:04:43 PM11/11/12
to knock...@googlegroups.com
One option I have been investigating, although not for a while, is
Simperium. This has a nice real-time sync of data between clients.
I do have a knockout plugin in the works that uses this, but it's a
side project I have not had time to work on for months.
Matt.
Reply all
Reply to author
Forward
0 new messages