Will GraphQL replace Redux?

We barely use Redux anymore now that we're using GraphQL

We went from tons of stuff in Redux to almost nothing

Now with apollo-link-state (https://www.apollographql.com/docs/link/links/state.html) you can even use GraphQL for the things you use Redux for!

I don't know how popular that will be, but it's an option

That's a strong argument!

to almost nothing? is there something left?

No

You can use redux for UI stat

There is something left, which is the current user data

GraphQL is a query language while Redux is a library for state management. Two completely different things. You may say that Apollo client will replace Redux, which might be true, but even that's is inaccurate today, because Apollo uses Redux under the hood. However, since I'm using Apollo and GraphQL and haven't wrote a single reducer (yet). There're several hooks to update state after mutation/query/subscription and writing a custom reducer is the last choice.

Apollo Client doesn't use Redux under the hood anymore since v2

Ah, sorry, I missed this change!

While graohql is a query language for you data

indeed, apollo-link-state is a better option than redux for domain logic state, as for UI needs, I believe https://github.com/renatorib/react-powerplug covers most of them

It will, but probably only for people who are using GraphQL for other APIs as well unless "moving the api gateway to the client side" becomes more popular... Now that I think about it that could easily be it's own talk.

This feels like a weird statement. A query protocol replacing a front end state management lib. We will always need both of those things. Optimistic updates Can’t be done without state management. Offline first. The question needs rewording. Maybe “Is it worth managing our own state now that Apollo or Relay do it so well?” For our application the answer to that question is yes, we do optimistic updates and server sent events that need reconciling on the front end. If either Apollo or Relay can handles SSEs our the box please fill me in.

FWIW, we also have lost the need for any type state management library since replacing our REST APIs with GraphQL endpoints. The state management our UI does need now (not much) works great with vanilla React state.

Any articles on this? I'm very confused.

Hi James, here's one article anyway: https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a

From our experience, most of our state management code was all trying to merge state from our API server and manage the asynchronous nature of all that. Once we switched to GraphQL, those issues were gone and we no longer had to manage business state in a store at all.w Hope that helps!

@mxstbr how are you managing the routing? is that graphql? i wonder if you could use a component or the context API to replace that piece of redux 🤔

not all applications can use graphql, especially those that really don't have a backend. could also use graphql queries directly and cache the response data in redux - sometimes the existing cache strategies with apollo or urql aren't enough. redux isn't going anywhere

If you ask me - redux is here to stay. As @cjhowe7 said many apps don't use any backend per se. And you have to have state in check :D

Can anyone explain to me how a query language and a state management library are comparable? Perhaps any links? I'm in the process of learning Redux, and have GraphQL in my sights as well. So learning when to use one as opposed to the other would be great info :)

They aren't. The GraphQL query language is completely independent from the GraphQL *client library*. The thing is, a lot of GraphQL client libraries include a caching mechanism to manage the data that is pulled from a GraphQL backend. So the "state management" part is really just some GraphQL clients managing cached GraphQL data. This is completely optional though, and you can use GraphQL without it, potentially with Redux.

sidebar: does any one have any good resources for one just starting graphql?

I have a question,

If we don't use redux, we can't use the middleware such as redux-saga, I used to deal with business logic and side effects in redux-saga.

So my question is, if you switch to GraphQL, where will these business logic be? in the components?

Hi all, inspired by this thread, I've drafted an article about how our team ended up losing the need for state management libraries after switching to GraphQL. This is still a draft so please don't share yet, but I'd love to get your feedback on the post: https://medium.com/@wmdmark/how-graphql-replaces-redux-3fff8289221d

@obiknows You can learn everything about GraphQL here: https://howtographql.com 😇

@wmdmark seems like a good post, but I have the feeling that using both is a better way of doing stuff. ie. How do you handle navigation/routing on react-native with

@skyzohkey I've never understood using Redux for navigation/routing... why would you need to do that? It seems like way overkill unless I'm missing something...

what about react-router?

@wmdmark Using redux for 'navigation has several advantages, I'm too lazy to explain them ATM but this SO post might explain better than me https://stackoverflow.com/questions/47104756/what-is-the-advantage-of-using-redux-integration-in-react-navigation

@arkee react-router-* also supports redux

Having the routing logic coupled to redux allows for example to implement time travel around your app by also taking the current screen in consideration. You can do it w/o Redux, but that would be more a mess IMHO.

@skyzohkey, @wmdmark could timetravel this be done with graphql/apollo somehow?

@arkee if you're using Apollo w/ the Redux Cache, I would imagine that would work 👍

@skyzohkey that makes sense but it still seems like overkill for most apps IMO. Also I've never found time travel to be particularly useful in practice although it's a really cool feature.

I'm currently working on a react+react-native bug reporting solution and it involves time travel, basically I record the redux state, replace the sensitive keys (auth, username, personal informations) by some placeholder, etc. Then I send the whole state serialized and encrypted to my bug-report server. That way when a new issue is found I get the imediate path user has followed to get the error. Permits me to reproduce & fix it faster ;)

Apollo never had a good integration with Redux beyond time-traveling. In Addition Apollo isn't synonymous with query components--that's just sugar on their powerful caching architecture. If React had the notion of "controllers" as in Redux-First Router (https://github.com/faceyspacey/redux-first-router) & we fetched from our global route abstraction instead, graphql results could go into our Redux store de-normalized. That would mean you could far more easily select the combination of UI state + graphql domain state in `connect`. Currently, most people get the denormalized results as props to components, and have very little means to properly integrate with what's in redux. ...That's something I'm working on, as I've found the complexity of doing so much in components to have spiraled out of control. The return of the ancient wisdom of "controllers" and "separation of concerns" is on its way. Fetching doesn't need to be done in nested components; you can figure out all the fetching you're gonna have to do based on the URL + cookies/etc. Like for 99.99% of most apps. If you're using state in your view layer to figure out what to fetch, that's very likely because of other async work higher up the component tree that also could be moved to the global controller/routing layer.

ApolloClient will replace Redux, not GraphQL. :D

I am curious how side effects are handled with ApolloClient. Is there a good practice to replace for example redux-saga?

We haven't had a need at all to use redux-saga (or anything like it) at Spectrum

I think that's specific to our app though, I don't think there's anything like Redux Saga for Apollo Client

§

when refresh, why I can't show the page in React?

I feel like Redux has been put to use in many cases where it shouldn't have (guilty of this myself). In my case, it was mostly because of a lack of experience with the stack, and the problems of modern web development. After writing a ton of Redux boilerplate around data fetching, one starts to realize this is not where Redux shines.

I actually feel like the cases where Redux really shines - cases of very complex local state, perhaps games and such - are more edge-cases than they are the norm. For your average web-app, I would rather guess that Apollo's model of data fetching covers way more of the average usage.

If you are using GraphQL with Apollo, then I reckon Redux is not needed as all the queries are cached and once cached, it does not make a request to the server anymore so you can just keep calling the query without worrying about network overhead. Also with Apollo link state, you can manage app state as you do on GraphQL server.

I've reduced a ton of our redux usage by using apollo. We still have some redux, but it's mostly for that kinda state that "doesn't matter after a refresh"... We haven't really looked back..

I'll give someone 5 dollars to DM me and tell me what problems redux-saga actually solves! Still don't really get it.