Meteor server-render package is really great and enabled me to achieve a first paint of less than 1.4 seconds (used to to be almost 4 seconds) so I’m very grateful that @benjamn took this initiative.
But it seems we’re running into a limitation with the current implementation. We’re unable to infer any user information at the sink object, ideally we would’ve access to the userId and the request cookies in the server sink object so we dynamically generate html based on their state and data. There is currently an open issue discussing the need of extending the sink object.
Meteor uses client localstorage and then sockets to store and communicate the user session however this context in not available when doing SSR. The fast-render package had a workaround for this limitation by grabbing the user localstorage token from the client and passing it as a cookie and then it uses this cookie to grab the user at the server.
Using the user token to fetch the user data when doing SSR has some security concerns that were discussed here, and here.
Emily Stark from MDG already pointed out 3 years ago that at some point cookies and local storage need to co-exist for Meteor SSR to work. Here is an excerpt from her blog post:
Perhaps a good first step is to extend the sink object request to include the cookies information which would allow us to create a package that inject the user data into the sink object, this should not be hard to do, I think it’s single block of code that needs to be modified in the webapp_server.js file. In addition to the cookies, ideally a userId field would also be available in the sink object if the user is logged in which can be used to retrieve user specific data.
What do you guys think?