8 ms·
They mention it in the article but forgot the caveat in the title: How GraphQL[1] Replaces[2] Redux [1] Or any well designed back end API [2] For some narr
by duckfruit 9y ago
They mention it in the article but forgot the caveat in the title:
How GraphQL[1] Replaces[2] Redux
[1] Or any well designed back end API
[2] For some narrow, often simple applications. And even in those cases it usually doesn't replace redux as much as it augments it.
- Blackstone4 9y agoI've been using Apollo Client and React to manage state on a medium size React app (i.e. no Redux). Interested to hear your thoughts here. Have you been using Redux + Apollo Client + React on a medium to large app?
- abritinthebay 9y agoThat's not GraphQL replacing Redux - that's Relay (ie, Apollo) replacing Redux. So yes, you can replace Redux with something different. There are pros and cons to it, but it's not required or even fundamental to implementing GraphQL in a React app
- duckfruit 9y agoI've only used GraphQL (with Relay) on fairly large apps but in my experience the number of apps that don't benefit from some sort of client side state management tends to fall into a very small window. Introducing state management doesn't come for free, of course. That is an extra layer of complexity that you have to reason and maintain. And if your app doesn't need any client side caching or you don't envision a need to have shared state between your components maybe you don't need to have something like Redux. But I feel like the use cases for those sort of apps tend to be pretty narrow. edit: Another commenter mentioned a good point that gets to the heart of your question better than my rambling -- You are still managing state in your app - just with Apollo instead of Redux.
- atom_arranger 9y agoWhat about client side state? Form validations? Any sort of user input before it's being sent to the server. You also may need ways to handle persistence or offline use. There are some new features in Apollo for handling client side state but I'm sticking to Redux for now (for client side state, I am using Apollo for some data fetching).
- wmdmark 9y agoFair points. The thing that tipped in favor of GraphQL for the back-end was that it puts the client in charge of the data structure. I suppose you could hack something like that with REST but it would be difficult. Our application is by no means narrow or simple and GraphQL (without Redux) has been perfect. I don't dislike Redux, we just didn't need it after switching to GraphQL.
- matte_black 9y agoCould controlling the shape of the data returned by GraphQL on the client open up your application to really inefficient querying? We control what is returned in data from our REST API by merely specifying the fields you want as a parameter. If there are use cases that would require multiple tables to be joined, those are created ahead of time as views with appropriate triggers for updates and then endpoints are created for accessing that view through RESTful methods. This has always worked just fine.
- _xgw 9y agoDoesn't that lead to an explosion of the number of sql views and backend controllers/endpoints?
- matte_black 9y agoNot at all. Not sure what other people are trying to do though.
- joshribakoff 9y agoBeing able to stay agile & change the app, without breaking old versions of the app, and without having to have an explosion of ad-hoc end-points for every change you've ever made. With graphQL its perfectly reasonable to never rename or delete fields, and never break backwards compatibility. With REST that would not work & would result in over-fetching, or tons of ad-hoc end points for every query you've ever written.
- 9y ago