[tonyjstark]

I have the same feeling, it seems overly complicated and I pity the developers that join the project at a later stage.

I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

Zeplin works quite well for our team and creates a nice connection to our designers. Storybook on the other hand not so much. At first we developers used it, then we had to update some things for Apollo but Storybook was not ready for that. Now everything runs again but nobody uses Storybook actively anymore...

I have the feeling that the software industry is often driven by personal preference instead of sane decisions. I see projects that use micro services without any reason, using React for static content, dockerizing everything to a ridiculous amount, K8s because why not. All of that because it's interesting for the developer not because it's good for the user.

[ordinaryperson]

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website?

Exactly. Forced to use GraphQL at work for an internal-only API and what a nightmare - what would be a nice, one-line REST API query can take hundreds of lines (not exaggerating).

If you're serving a public-facing API at massive scale, yes, GraphQL will save you bandwidth. If not, what a pain in the *. For most engineers it's a solution in search of a problem.

[qudat]

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

I work primarily as a FE software engineer who spends a lot of time researching, using the JS ecosystem. I have gone through graphQL/apollo docs multiple times in order to really understand the value add. Fetching/bandwidth/caching/persistence appear to be the biggest value adds for the tech. To me, these are the easiest things to do in a react/redux SPA. Fetching data isn't difficult, it's all the derived state data that is the hard part. Most of the "business" logic for me is formatting the data in a way that makes sense for whatever UI component I'm building, combining multiple streams of data for the UI, when to refresh data, optimistic UI, and offline support. To me the "declarative fetching" is not really that much a sell to me, because that piece of many projects of even intermediate size is relatively small.

I realize that apollo is trying to solve some of the optimistic UI, offline support, but it does not seem to fit super well atm. The other really big issue I have with apollo is like you stated: it's easy until you want to do something that it can't do. This is the worst position to be in because for 80% of the use-cases it works, but that other 20% where it doesn't fit at all can make a team's life a living hell.

Not to mention most of the time, for any large enough SPA, you will still need redux. If I still need redux then apollo solves nothing for me.

[WorldMaker]

Most of the stuff that you need Redux for you should be able to handle with @client [1], and the local "resolvers" approach isn't too different from Redux reducers, to the point that wrapping Redux-style reducers as Apollo resolvers seems like it should be boring/trivial to implement. It would probably be cool to have something of a "standard library" for that which let you easily convert Redux-style reducers directly (ie, a sort of combineReducers that spits out local resolvers). I don't think it should be hard to do, just doesn't look like anyone has done it yet.

Of course the bigger issue, though, is the Redux Dev Tools/Thunks/Sagas/Observables ecosystem where you want a richer experience and/or already have existing code investments. Apollo has some equivalents to those (Apollo Dev Tools; resolvers can return promises, taking care of a lot of basic thunks/sagas), but it probably needs richer options for others. I know redux-observable is currently a big need for several of my applications and I don't currently know any way to approach that in Apollo other than maybe trying my luck with a custom "Link" and that API looks more intimidating than it probably is, enough so that I haven't had the investment need to approach it. (Then again, most of my applications need to be offline-first so GraphQL in general isn't a great fit for them, though Apollo looks like options might be possible eventually, if someone built a little more infrastructure [Links] for them.)

[1] https://www.apollographql.com/docs/tutorial/local-state.html