Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sever-side rendering #92

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Support sever-side rendering #92

wants to merge 1 commit into from

Conversation

elmarti
Copy link

@elmarti elmarti commented Jan 3, 2017

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
Copy link
Author

elmarti commented Jan 3, 2017

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
Copy link
Author

elmarti commented Jan 3, 2017

#80

@boxofrox
Copy link
Contributor

boxofrox commented Jan 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants