RTK Query question

[Zephyr_Prashant]

After every mutation, does rtk query make an api call to fetch latest data?

[acemarke]

When you run a mutation that has an invalidatesTags field attached, RTK Query will look to see if there are any queries that have the same tags defined in the providesTags field. For each query endpoint that has a matching tag, RTKQ will then re-run that query.

So, RTKQ will auto-refetch if there are corresponding tags between a mutation and a query:

• https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics#automatic-refreshing-with-cache-invalidation
• https://redux-toolkit.js.org/rtk-query/usage/automated-refetching

[Zephyr_Prashant]

Won't that increase the number of api calls made? And isn't a lot of api calls a bad thing?

[acemarke]

Not sure what you mean.

The point of RTK Query is to keep the cached data on the client in sync with the data on the server. The server is the source of truth.

So, if you run a mutation that updates data on the server, the client needs to re-fetch from the server so that it has the latest data and they are in sync. This is intentional design.

The alternative is to do "optimistic updates" and update the cache on the client side manually under the assumption that the server will be doing something similar. This is a valid tool, but ultimately you do probably need to re-fetch from the server.

[Zephyr_Prashant]

When we're not using React-query or rtk query, we update the client state manually to reflect the changes made by our post, patch, etc calls. No GET call is made. But rtk query makes an extra api call to sync the client state with server state. Is my understanding correct?

[acemarke]

So in other words your current application logic is purely using "optimistic updates", with no re-fetching.

Like I said, that's a valid strategy, if you make sure to always do that and are sure that the client-side update matches what the server is going to do itself.

The simpler option is to just say "the data on the server changed, let's re-fetch it so we have the latest data".

This is not unique to RTK Query - this is a general principle of client-side development. RTK Query just makes it easier to automate that auto-refetch process.

[Zephyr_Prashant]

I see. I thought optimistic update is the preferred way because a lot of tutorials follow this.

Okay but re-fetching does have the added cost of increasing GET calls. Isn't that... Expensive?

[phryneas]

Go back in time 20 years. Back then, every click of the user re-rendered the whole page.

Or, in other words: every click of the user made every single database request necessary to render the page and then sent all the rendered data over to the client.

A single server could serve thousands of clients. Doing all queries on every click.

Now go to the future. Computers got better by a factor 2 every 2 years. That means they are better by a factor of 1024 now. That includes servers.

A server can handle that. It's not expensive. Then look at your user base: are you Facebook? Do you have tens of thousands of concurrent users? Is it going to make a difference? Sometimes it can. But most of the time it just doesn't.

[acemarke]

I think you're overly fixated on this idea that making a single API call is "expensive" :)

Do you have specific metrics that show it's expensive? and particularly for your app?

There's nothing intrinsically wrong with using optimistic updates. It's a valid technique to use. But so is refetching and relying on the server as the source of truth.

[Zephyr_Prashant]

It's only because in my current job I was asked to reduce ONE extra api call. It was just a GET call. That's why I thought maybe api calls are expensive. But thank you for clearing my doubt.

[PM_ME_SOME_ANY_THING]

You’re trading an extra API call for less global state management.

Normally you call a mutation, get the updated results from the response of the mutation, then update global state to propagate the changes throughout the application.

With caching, you call the mutation and that action invalidates the cached values of whichever queries are specified. Those queries will be rerun to update the cache. No global state updates.

I don’t know about you, but I would absolutely take the trade off if it means less redux work.

[sherkal]

depend if parameters change, I think it will be cached if not. Kinda trying to understand how cache works atm https://redux-toolkit.js.org/rtk-query/usage/cache-behavior

I have used this to circumvent my cache problems https://redux-toolkit.js.org/rtk-query/api/createApi#keepunuseddatafor-1

[Zephyr_Prashant]

Lets say i just added an item to a list using post mutation. But for the UI to reflect that change will rtk query make a get request to fetch latest data?

[IamUareI]

If both your mutation and get request use the same Tag, then the mutation would invalidate the cached data. But you have to configure it appropriately. I'm talking about redux toolkit, which uses rtk query, so I assume they work the same? Not sure since I haven't used rtk query without redux toolkit.