Is it safe to use createSelector in SSR?

[aleksakojadinovic]

Hi,

I have a setup using Next.js 12 and Redux (RTK/RTKQ), using next-redux-wrapper.

It suddenly occurred to me that it might not be safe to use createSelector in SSR environments as it might cause cross-request data leakage. The thing I'm worried about is the built-in createSelector memoization, since the selectors are defined globally (not scoped to the request). This seems like it could case a scenario where one user can request a page that is server-side rendered and invokes a selector on the server, and then another user could get the same result from the cache, causing potential data leakage.

I've looked into the source code a bit and it seems like this could be a major issue for me, but I wanted to first check whether someone else has investigated this more thoroughly before I start making big changes. What confuses me further is the README saying the following:

createSelector determines if the value returned by an input-selector has changed between calls using reference equality (===). Inputs to selectors created with createSelector should be immutable.

This makes me think it might be safe after all, since the original states will have different references. But this, in turn, confuses me about how the memoization works after all if reference checks are applied everywhere.

I wrote this as a discussion rather than an issue since this isn't really a library problem (because it was not originally meant to be running in server environments).

Thanks in advance :)

[markerikson]

I think that the reference checks are exactly why this shouldn't be an issue. But also I think this is a somewhat mistaken concern (?).

Every SSR request should have an entirely separate Redux store to begin with, because different users may have different data needs + the actual leakage concerns.

If I have a single selector instance, ie const selectTodos = createSelector(.....), it is indeed a shared cache, and using that across different requests could conceptually "share" results in a sense. BUT:

• Since every Redux store will have a different state reference, selectTodos(store1.getState()) and selectTodos(store2.getState()) will force the selector to recalculate because it's grabbing different state.todos references
• Even if somehow the selector ended up reusing a cached value, well... that means that the input data was the same across both calls, and thus it's correct to return the same value

So, I understand your concern, but I'm pretty sure there's actually nothing to worry about here.

[aleksakojadinovic]

Thanks for the fast reply :)

Yeah it does seem kind of obvious now, I guess my initial confusion came from wondering how the cache works at all if reference checks are applied, but apparently I forgot the most important rule - immutability.

Anyway, at the risk of going off-topic, I'd like to ask a followup question if you don't mind:

Even though it is safe in terms of data leakage, is it smart to use it on the server at all? Considering:

1. The cache will be useless (on the server). What I mean by this is that every subsequent request that performs store selection on the server will indeed operate on a completely different instance of the store (even when the same user navigates the store will still be freshly created). So this guarantees cache misses every time. Would you say it is a good idea for me to completely disable memoization on the server? For example creating my own instance of createSelector through createSelectorCreator that uses either default memoization function (on the client) or a dummy memoization function (on the server). Something like this:

import { createSelectorCreator, defaultMemoize } from 'reselect';

export const createStoreSelector = createSelectorCreator(
  typeof window === 'undefined' ? (func) => func : defaultMemoize
);

2. It might consume unnecessary memory. Since cache will always be missed on the server, this unnecessarily consumes RAM. Furthermore the consumption increases with the number of selectors defined through createSelector, and for redux-based applications (especially RTK & RTKQ) almost every non-trivial feature will define some slices and alongside them selectors.

Again, this might be off-topic from the original discussion theme, but I might as well ask here instead of creating another one.

Thanks again :)

[markerikson]

I wouldn't say that "cache is useless / will always be missed". Certainly a lot of the selectors will be seeing fresh state, but you might also be sharing the same selector across several different components.

Beyond that, this seems like an awful lot of effort to go through to differentiate client and server behavior, when half the point of SSR is to share code between client and server.

[aleksakojadinovic]

Yes, technically the memoized value could be reused deeper in the component tree during the server render cycle for one request. But this assumes that no other user request arrives in between. While not a race-condition per se since it won't cause actual issues, in a website with somewhat higher traffic this seems like a lottery.

So I guess the decision comes down to - should we keep server-side memoization, intentionally utilizing more RAM, knowing that multiple concurrent requests can keep invalidating each other's cache? Or should we opt out of it completely on the server to save us the RAM (I might be overthinking it here, no idea how much the actual RAM usage increase could be, but as I said before it certainly grows with the number of selectors).

As for

Beyond that, this seems like an awful lot of effort to go through to differentiate client and server behavior, when half the point of SSR is to share code between client and server.

It really doesn't seem like an awful lot of work, it's just one wrapper and an eslint rule can be created to remind developers not to use default createSelector's (either from @reduxjs/toolkit or reselect).
And yes, I agree that half the point of React SSR is to share code, or rather it should be. However in my experience (at least with Next.js), in enterprise applications you have to rely on these kind of checks more often than you'd expect (docs and examples are usually based on very minimal toy projects and not real-world application needs).

[markerikson]

If you feel you need to enforce that in your app, it's up to you, but I don't think there's anything we ought to do in the library itself.

[aleksakojadinovic]

No I completely agree, as I stated originally this isn't a library issue. I was merely trying to get some advice on proper usage in SSR. However it seems now I have gone much too off-topic, therefore I'll close this, thanks.