arunoda
commented
9 years ago Actually, this is harder than it seems to do it correct. If we are doing this, it needs to be perfect and we don't need to loose data data.
Here's a one way to do it.
1) Cache fast-render docs on the server temporarly and create an ID 2) Then when the DDP connection is creating, send a that ID to the server 3) Then pick fast-rendered data to put them back to the mergeBox without sending to the client 4) Then let subscriptions to work as normally
This can be done, but I'm not sure how exactly we can do it at this moment.
On Sun Feb 15 2015 at 6:15:15 PM Sergey Petrov notifications@github.com wrote:
When we use fast render, we have copy of our data injected into HTML. It provides faster overall response time for initial page load.
However, right after that 'real' subscriptions come through websockets, creating unnecessary load on meteor websocket connection.
In systems with low bandwidth capabilities (GSM connection to server) it may compromise whole connection (various timeouts come to play).
I wonder, how can I work around that and never send two copies of one object.
First, I thought it was simple: let's check in publication method if subscription is real and if it is instead of returning cursor use observeChanges to send events, skipping initial 'added' events because it was sent already as injected data.
Problem was that 'changed' and 'removed' events fail due to lack of initial 'added' event on server. Meteor caches every client's data on server and needs to have object already sent in order to send 'changed' or 'removed' event.
Now, I just send empty 'added' events. It leads to insignificant error on the client side (object already added), but works well.
However, I'm trying to find any way to not send initial data through websockets at all.
Can you guide me on how can I do that? I think that it could be nice improvement to fast-render packages and I'd love to work on PR.
— Reply to this email directly or view it on GitHub https://github.com/meteorhacks/fast-render/issues/98.
maxnowack
When we use fast render, we have copy of our data injected into HTML. It provides faster overall response time for initial page load.
However, right after that 'real' subscriptions come through websockets, creating unnecessary load on meteor websocket connection.
In systems with low bandwidth capabilities (GSM connection to server) it may compromise whole connection (various timeouts come to play).
I wonder, how can I work around that and never send two copies of one object.
First, I thought it was simple: let's check in publication method if subscription is real and if it is instead of returning cursor use observeChanges to send events, skipping initial 'added' events because it was sent already as injected data.
Problem was that 'changed' and 'removed' events fail due to lack of initial 'added' event on server. Meteor caches every client's data on server and needs to have object already sent in order to send 'changed' or 'removed' event.
Now, I just send empty 'added' events. It leads to insignificant error on the client side (object already added), but works well.
However, I'm trying to find any way to not send initial data through websockets at all.
Can you guide me on how can I do that? I think that it could be nice improvement to fast-render packages and I'd love to work on PR.