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

Disabling SSR? #52

Open
pdfowler opened this issue Jun 21, 2018 · 7 comments
Open

Disabling SSR? #52

pdfowler opened this issue Jun 21, 2018 · 7 comments

Comments

@pdfowler
Copy link
Contributor

@foxhound87 - We've been diagnosing (and fixing) some crazy SSR issues that happen with simultaneous requests. Basically, the second request corrupts the state of the MobX stores and all sorts of uncertainty results. (I'll be reaching out separately to get your input on that)

Where we are right now however is searching for a solution to disabling SSR for production - basically making it run like web:dev. We're having some trouble since the state and SSR stuff is so integral to the setup - everything we try has resulted in hard errors.

The two main points we are trying to solve:

  1. Properly initializing the stores and calling fetchData on the components when the load client-side
  2. Removing or replacing the code in src/web/ssr.js to simply render everything client side.

Thoughts?

@foxhound87
Copy link
Owner

Hi @pdfowler,

please, can you provide more info about and how to reproduce this issue?

Anyway, removing the SSR code is not recommended,
if you don't need SSR I suggest you use something else like:
https://github.com/facebook/create-react-app

@pdfowler
Copy link
Contributor Author

Thanks for the reply. We're a bit too invested in the rfx-stack at this point, so we've taken an alternate approach. The problem manifests when two concurrent requests hit the server for two different logged in users. What appears to be happening is as follows:

  1. User A's request hits the server first, fetchData is called and begins executing
  2. User B's request hits the server a ms later, fetchData is called and begins executing
  3. User B's fetchData mutates the state of the app's mobx store, corrupting User A's request.

I have tried several methods to separate out the stores on a per-request basis, but have had no success. The closest I got resulted in the MobX error complaining about having multiple stores.

Our solution for now has been to do the following:

  • When SSR runs, authenticate and do basic setup for the user. Do NOT run fetchData, set an empty object for window.__STATE. The results in a quickly rendered app chrome including menu bar, and general look & feel.
  • When the client starts, detect the empty window.__STATE and execute fetchData on the client based on the client's jwt.

While the root problem remains that an incorrect user's name or company may be rendered into the header, it eliminates the possibility of another user's (private) data being rendered in one of the main body components.

@foxhound87
Copy link
Owner

foxhound87 commented Jun 27, 2018

Your issue seems related to this one: feathersjs-ecosystem/authentication-client#99

If so, this is my workaround (I'm using feathers buzzard, not tested with the version used in this repo).

In the auth store update the code of the jwtAuth method as below:

  jwtAuth({ token }) {
    if (!isClient) {
      app().set('accessToken', token);
      return this.verifyToken(token)
        .then(payload => this.loadUser(payload.userId));
    }

    return app()
      .authenticate({ strategy: 'jwt', accessToken: token })
      .then(response => this.verifyToken(response.accessToken))
      .then(payload => this.loadUser(payload.userId));
  }

@pdfowler
Copy link
Contributor Author

pdfowler commented Jun 27, 2018

That's the exact issue that gave us a great amount of hope last week, but after some initial success, we were still able to repro the issue. We're on feathers v3 buzzard as well.

We've tabled the issue for now and will revisit down the line. Thanks for digging a bit.

Also, I've got a big update to rfx that I'm queuing up in my repo that brings most of the libraries up to date - MobX 5, Feathers 3, Prettier, React Router 4 (still pending), etc. I've taken a lot of the things we've learned building a product on top of the stack and applied it to my repo. Once we move it over to our org's repo, we should be ready to submit a PR. You can see the changes here: https://github.com/pdfowler/rfx-stack/tree/feature/rfx_v2

@foxhound87
Copy link
Owner

@pdfowler Your updates are very appreciated.

Can the issue be reproduced also with the current repo?

@pdfowler
Copy link
Contributor Author

I’ll see if I can reproduce it tonight ...

@foxhound87
Copy link
Owner

foxhound87 commented Feb 23, 2019

Any updates on this?

If you still have this issue, I just published a new repo which can be interested for you.

https://github.com/foxhound87/rfx-next

It's a new stack based on Next.js with all the functionalities of rfx-stack,
like mobx support, rfx-core state mgmt, tachyons and Material UI 3.

The new app si pretty fast to develop and deploy compared to the rfx-stack.

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

No branches or pull requests

2 participants