Comments (14)
Yes, security should come first. Sharing cache data between users is a top concern for apps, but not technically something React-Query can control. Something I'm asking myself is this, if you weren't doing server-side rendering, and just requesting data
, wouldn't you be sending some type of identifier or token to get user-specific data, then validating that token for access to it?
I bring this up because for our discussions sake, you could technically add a userId
variable to the query and you would no longer be sharing cache results. In fact, for multi-user apps, it's almost expected that if the app doesn't clear the query cache when user context changes (log-in/log-out), then userId
should be represented as a variable in almost every query, so as to result in a different query hash for different users. That would technically be the only way to store multi-user data in the same cache without security concerns.
To clarify on your other findings, I believe that allowing initialData
seed an empty cache instead of only acting as a fallback is actually an awesome and expressive feature of the API.
So after talking this through I think the best course of action is that if you want to cache data in the server context, you should either (1) try to use a query id or variable that will allow multi-users to exist in the cache at the same time (2) clear the cache when user context changes
More about (2) from above, the more I talk through it in my head, the more I don't feel like caching query results in the server is a good idea at all. It makes me think that there should simply be a way to opt out of using the cache at all, or simply force react-query to not cache on the server. I feel like it will only lead to major headaches and like you have illustrated here, security problems.
Thoughts?
from react-query.
Version 0.3.22 is now available with caching disabled when typeof window === 'undefined'.
from react-query.
So it sounds to me like you are asking for a way to disable caching when react-query is used on the server, is that right? Outside of that, React Query is doing what it was designed to do, albeit, in the client. So let me ask, are there situations where you would want to use the cached value from useQuery
on the server?
from react-query.
you are asking for a way to disable caching when react-query is used on the server, is that right?
Not sure about that. I think caching on server isn't an issue as long as that cache is not shared between page requests.
But what wonders me the most is that swr
doesn't suffer from that issue, although conceptually its caching mechanism works very similarly (correct me if I'm wrong).
I briefly looked through swr
source code, but didn't find any code specific to this issue.
from react-query.
Hmmm. One guess is that in SWR, initialData may somehow be overriding the cached data. IMO, it shouldn't.
The other idea is that maybe initialData
is somehow updating the query cache?
Regardless of what SWR does, we can figure out a way to fix this. Some of my thoughts keep going back to the idea that this use case is a bit contrived. I would really like to know how you're approaching this in a real example to better know what course of action to take.
from react-query.
Huh, looked at swr
code once again and I think I've found the key difference.
In swr
initialData
isn't saved to cache, but used as a fallback when returning results - see https://github.com/zeit/swr/blob/05779e6c892e9dac9007faa37044c3aa5fb8cd69/src/use-swr.ts#L563
In react-query
initialData
is stored in cache.
So in swr
cache is never modified on server.
So the fix would be to not store initialData
in cache, but simply use it as a fallback
I will willingly work on PR, but source code in the repo is outdated (I've checked initialData
implementation in production build from NPM).
from react-query.
I would really like to know how you're approaching this in a real example to better know what course of action to take.
Yes, I intentionally made that example to be as simple as possible.
I'm mostly worried about security in this case.
I think the real-life use case would be SSRing user data:
- logged-in user enters dashboard page (rendered on a server)
- html rendered on server contains data of the first user whose dashboard was rendered after server has started
from react-query.
initialData may somehow be overriding the cached data.
Yes, that's exactly what I've discovered.
IMO, it shouldn't.
Can you elaborate on this?
from react-query.
wouldn't you be sending some type of identifier or token to get user-specific data, then validating that token for access to it?
Yes, this is valid point - user data are protected on the backend side.
then userId should be represented as a variable in almost every query
I don't think it's obvious for developers. If user id isn't required by API endpoint (it's a common case from my experience), I don't think anyone would bother to provide one as query variable.
I believe that allowing initialData seed an empty cache instead of only acting as a fallback is actually an awesome and expressive feature of the API.
I agree, that prefilling cache with initialData
is more elegant solution, but are there benefits from user's/developer's perspective?
the more I don't feel like caching query results in the server is a good idea at all
Yes, I agree. Caching query result on server doesn't make any sense to me now.
What can we do to disable it?
from react-query.
I think a good question here is "should we disable caching by defualt in server-side scenarios?"
I think the answer is yes. I feel like the only feature people should be using during SSR is initialData
, which doesn't technically rely on persisting anything to the cache, it's merely there for rendering an initial state on the server. After that, the cache state is relatively useless until it gets to the client.
from react-query.
should we disable caching by defualt in server-side scenarios?
Yes, I agree.
BTW, looks like using initialData
as a fallback has drawbacks like this vercel/swr#178
from react-query.
😂 Yeah, I don't think React Query has that issue. Once initialData is ingested into the query, the null
data state isn't possible (unless initialData is null, I guess). Even during pagination, the data
state is never null
or reset (not sure why SWR would be doing that regardless).
from react-query.
@tannerlinsley Cool, thanks a lot!
I'll check this out
from react-query.
@tannerlinsley works like a charm, thanks again!
from react-query.
Related Issues (20)
- onSuccess, onSettled do not work in svelte-query HOT 1
- Errors for shared queryKeys cause all queryFn to run, even if disabled HOT 1
- Handling Persistent Storage Overflow with TanStack Query and persister HOT 2
- Docs: Broken links in react suspense guide HOT 1
- Dependent useQueries creates too many updates (exceeds maximum update depth) HOT 2
- Order matters to useInfiniteQuery options and TS HOT 4
- [vue-query] `useQueries` type inference issues with `select`, `computed` and `Array.map` HOT 1
- enabled: false should not ever fire a query or populate the local store HOT 1
- Solid Query: <Suspense> gets stuck in a loading state HOT 9
- Docs: Broken link on "Installation" page HOT 1
- eslint-plugin-query is incompatible with Eslint 9.x
- Solid Query is mixing up queries during SSR HOT 2
- Docs : Remove ‘$’ from Installation Commands in Documentation
- SSR using NextJS App Router with InitialData Does not Callback HOT 4
- Changing `retryDelay` is ignored for query HOT 2
- Solid Query is failing to recognize signal change in `onMount` HOT 7
- Wrong inferring in useInfiniteQuery HOT 3
- Solid: Cannot access 'refetch' before initialization
- docs: search doesn't work HOT 1
- Docs website doesn't work in Brave HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-query.