How to rapidly seed a client collection with a subscription?

help
1

Hi,
I have a collection on the client that has a subscription. I have 4500 documents (lines/streets for a map) that gets sent to the client. The times that it took to populate the client collection on my development machine were (2900ms, 3266ms, 2809ms, 2772ms). Obviously these loading times become much longer on a remote production machine (>10s).

If I send the docs as an array to the client on my development machine using Meteor.call() the times are (1476ms, 1857ms, 1645ms, 1355ms). So the Meteor.call approach populates the collection in half the time required by a subscription. The downside is that the client collection does not get updated if a doc changes on the server.

Is there a way to rapidly seed the client collection (Meteor.call or similar) but keep the subscription for when the docs on the server changes?

2

ok, I realize that when you do a meteor.call the data ends up on the client side and you cannot modify the collection from the client side. So seeding needs to be done directly from the server into the client collection.

Instead of waiting for all 4500 docs to arrive, before displaying them on the client. I can probably display them as they arrive on the client (let the results fade in). This is probably simpler.

3

The fast-render package does something like this, have a look at that or one of it’s dependencies maybe.

4

4500 docs is a huge subscription. You most likely don’t want to be sending that much at any time. If you had multiple users on at once, it would cause a lot of stress on the server.

In that case you should probably set up some pagination. That way you can control how many documents get sent at once (for example, 20 per page, which would run beautifully even with multiple users). You can do this through a Meteor package. One I can recommend is: https://atmospherejs.com/electronifiejs/pages . It is similar to the Alethes pages package, but has some of the extremely critical errors fixed (specifically the ones that mess up the client side filters/sorting when you have multiple users). We are using it in our production app without any issues.

Also, it’s possible to write your own pagination system if you would like (we had to do this for some of our charting features since they use some pretty intense aggregation). It takes a bit more work/knowledge, but it is possible. If you would like to go this route I can give some advice on how to get your pagination up and running.

1 Like
5

You can, together with other things, select the fields you are going to use (for example, only the _id and ‘name’) and then fetch more information about individual documents.

6

I would inject them into the HTML payload. Just like fast-render, though it’s a discontinuated package. Therefore, I don’t recommend it.

Actually this is what I’m developing for an SSR package. The code is open, in a friendly license and should be straightforward (well, at least, I hope so :wink:): https://github.com/ssr-server/ssr

EDIT:
There’s also a demo that you can run and see the injected collections. Just open your devtools and check if with console.table(JSON.parse(__PRELOADED_STATE__).Folks).