Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest.
For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.
In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.
I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.
The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.
In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
> For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it.
Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.
> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.
The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls.
The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.