Support sever-side rendering

[elmarti]

Allow server side rendering when using React with kadira:flow-router-ssr. This allows all subscriptions to be processed on the server side without throwing an error.

[elmarti]

I realize now, that there is already a pull request for this, but I offer a solution without code repetition. If you are happy with this solution I will update the tests; all are passing, however I should remove some isClient conditions.

[elmarti]

#80

[boxofrox]

Keep in mind, it's been a over a year since I've worked with Meteor in a routine fashion, and never attempted server-side scripting (SSR), and know nothing of how flow-router-ssr works. I opposed this feature in the past for reasons [1].

[1]: #63 (comment)

Some concerns off the top of my head.

1. Doesn't SSR utilize the global namespace of your nodejs environment?

   1. How does SSR avoid leaking memory & collection observers when the client code subscribes in the server environment? If subscriptions aren't manually closed in SSR, then I expect your server to accumulate many collection observers that are trying to update the same keys/counts in the CountsCollection.

   2. How does SSR avoid race conditions/collisions? If we have one CountsCollection on the server to supply counts for all users via SSR. How does one user's request avoid writing to that single CountsCollection while a second user is trying to read from it for their SSR?

   3. Does SSR guarantee synchronous evaluation of subscriptions? publish-counts is designed to work with publications reactively. I vaguely recall devs in the past having problems with zero counts appearing before the server finally computed a count and pushed it to the client. Then again, this probably isn't an issue since Mongo synchronously delivers all documents in a collection to observer.added when the observer is first attached. I do expect this is to surprise devs using SSR when page loading time soars while waiting for this process to complete.

If SSR simulates a user-agent in an isolated environment that can be destroyed at the end of the request, then my concerns are moot, but if this was the case, why would we need CountsCollection on the server side? The current client-side code would create a Counts collection in that isolated environment.

I reserve the right to introduce other concerns as they come to me.

That said, I'm not 100% against this feature, but when I don't understand how a solution avoids introducing bugs in user applications, then I won't support it until I do.

Ultimately, I'd like @tmeasday to weigh in as he understands the goals of this project better than I, and this feature was generally considered beyond the scope of this package.