It's awesome to see you guys embracing server rendering, but it's incorrect to say most server-rendered Flux apps can only render one request at a time. If you're designing an isomorphic architecture, it's certainly a consideration, but I doubt any production apps have this limitation.
A common pattern is to instantiate a new store for every request, to avoid collisions.
The Flux fragmentation makes this hard to talk about. The examples I've seen from Facebook all use global singletons. There are some libraries/implementations that work correctly, but it's hard to know how widely used those are.
I guess the high order bit for me is that developers shouldn't have to worry about stuff like this—picking the "right" implementation of their app architecture. Ideally, everything just works out of the box. The harder it is to do, the less likely people are to do it.
Comments
It's awesome to see you guys embracing server rendering, but it's incorrect to say most server-rendered Flux apps can only render one request at a time. If you're designing an isomorphic architecture, it's certainly a consideration, but I doubt any production apps have this limitation.
A common pattern is to instantiate a new store for every request, to avoid collisions.
The Flux fragmentation makes this hard to talk about. The examples I've seen from Facebook all use global singletons. There are some libraries/implementations that work correctly, but it's hard to know how widely used those are.
I guess the high order bit for me is that developers shouldn't have to worry about stuff like this—picking the "right" implementation of their app architecture. Ideally, everything just works out of the box. The harder it is to do, the less likely people are to do it.