Side-loading data into minimongo

[gunn]

There should be a supported way to inject data directly into minimongo instead of by subscription and DDP, but still allow update by subscription later.

A common use case for this is to support SSR - the initial data to hydrate an app can be shipped as a JSON string with the html - library example.

In my app, eliminating the wait for the initial subscription would reduce page load time from ~4s to ~0.8s.

This code - https://github.com/kadirahq/fast-render/blob/master/lib/client/fast_render.js#L19-L90 might do the job, but it's 5 years old, and getting quite deep into meteor's internals.

[gunn]

It would be great if it was possible to inform the server that the documents were side-loaded so it didn't send the data again (although even if it does it's still a win).

The fast-render library has to monkey-patch some of Meteor's DDP methods to avoid errors when the same documents are loaded for a second time - https://github.com/kadirahq/fast-render/blob/master/lib/client/ddp_update.js

[filipenevola]

Hi @gunn, did you check this package https://github.com/pathable/meteor-fast-methods?

[gunn]

Hi @filipenevola no I hadn't seen it, thank you.
Looking it over now, it's a very similar approach to fast-render, and has the same short-comings - If you subscribe to the data it still gets sent a second time, it does invasive (and here non-tested) patching of meteor's internals.

I also can't see that it would prevent the error: Expected not to find a document already present for an add

This is a fundamental bit of functionality, so I'd like to avoid extra dependencies like redis too.

[Saeeed-B]

@gunn @filipenevola
Is it logical to check the server side of each route and return the appropriate data with it.
It costs a lot. And obviously not a good solution.