Decision at StackShare about Redux, Apollo, React, GraphQL, FrontEndFrameworks

Avatar of ruswerner
Lead Engineer at StackShare ·
ReduxReduxApolloApolloReactReactGraphQLGraphQL
#FrontEndFrameworks

Earlier this year we decided to go "all-in" on GraphQL to provide our front-end API. We needed a stable client library to power our React app. We decided to use Apollo Client for a few reasons:

1) Stability 2) Maturity 3) Heaps of features 4) Great documentation (with use cases) 5) Support for server-side rendering 6) Allowed us to stop using Redux and Mobx

Overall we've had great success with this library, along with a few minor hiccups and work arounds, but no show stoppers. If you are coming from Redux.js land, it takes a bit of time to settle into a new way of thinking about how your data is fetched and flows through your React app. This part has been the biggest learning curve of anything to do with GraphQL.

One of the downsides to Apollo Client, once you build a larger application, (past the size of most of the documented use cases and sample apps) the state management tends to get distributed through various places; and not just components. Apollo Client has a state management feature that relies on a normalised local cache. Mastering the knowledge of how this works is key to getting the most out of the library and to architecting your component hierarchy properly.

#FrontEndFrameworks

14 upvotes·1 comment·179.5K views
Shantanu Kotambkar
Shantanu Kotambkar
·
November 2nd 2018 at 3:59pm

Yes Having worked with GraphQL, and now React. i can surely say that Apollo is great wheb it comes to documentation, and use case descriptions. Great choice StackShare!

·
Reply
Avatar of Russel Werner

Russel Werner

Lead Engineer at StackShare