4 ms·

I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP h

I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP has. Its rough because Apollo does so much for you, its wonderful, but there are so many sharp edges and pitfalls - from the buggy devtools to the lack of/incorrect docs, major unanswered github issues & constant API breaking changes even on patch/minor version bumps, its been an uphill struggle all the way. All that said, it still seems like the best tool for the job, Relay still has a huge learning curve & has already had two major branches with no refactor path between (Classic/Modern) & the numerous other implementations all lack things Apollo gives you for free. If your usecase is simple, using Apollo to query a GQL server with a well defined schema doing little to no client state handling it can be pretty straightforward, but the complexity ramps up crazy quick as soon as you start messing around with caches or persistence or local state. The Apollo folks seem to have a handle on things but hopefully I/we can start contributing back, if not with feature work than with documentation

andrewingram 6y ago
That Relay rewrite was over 3 years ago though, and it’s been pretty stable since (the hooks API is coming “soon” but shouldn’t break compatibility). And there was an upgrade path, there was an intermediate compat version which let you incrementally upgrade. The learning curve isn’t that really that steep, it’s just made artificially so by the poor docs. It’s unfortunate that the Relay team doesn’t really prioritise getting new users, because it’d motivate them to explain things better. But there’s not actually that much to learn, you can be up and running and productive with it pretty quickly.
- consolenaut 6y ago
  True, and admittedly I've only cast a cursory glance over Relay to keep track of where it is every now and again so maybe its unfair of me to write it off quite so quickly. But I think you're also right about the learning curve being made artificially steep by the poor docs, and when you're introducing this stuff to a team who are already new to GraphQL, adding another framework on top with even poorer docs than Apollo is a hard sell
city41 6y ago
Are you sure you like Apollo? I ask because your comment says it's wonderful, but then gives a lot of reasons as to why it's not. I don't like Apollo on the client (no issue with it server side). I feel the sharp edges and pitfalls are numerous and it's a lot of boilerplate to get anything off the ground. To be totally fair to Apollo, I'm also not sure the projects I worked on really needed or benefited from GraphQL on the whole, so...
- consolenaut 6y ago
  I do on the whole yes, its not something I rave about unreservedly the same way I do about styled-components for example, but its still a tool I'd opt for on projects that actually have a need to do GQL stuff. Its like your favorite screwdriver that you somehow always manage to cut yourself on - you're extremely grateful that you have this tool, it lets you tighten screws even in the narrowest spots, you just wish the handle wasn't so damn sharp
undefinedzero 6y ago
I don't understand the problems you guys are running into with Apollo local state. I've been using Apollo rigorously for 2 years now (though not yet upgraded to v3), and my experience is the state is a blessing. In the past I had to write or figure out my own Redux solutions to store data from queries in the state and now that comes out of the box with Apollo. If I want to manipulate this state locally, I can just do a client.writeQuery in a standard JS function (no resolver bullshit). In the rare event I want purely client-side state, I can use the same method with the @client directive. I've never really needed resolvers as I can contain the logic in my `update` handlers or state manipulation (action) functions that look and behave like standard JS. Caching is great out of the box. You get all variations you might want (cache-first, cache-only, cache-and-network) and it's very easy to configure. Not sure what problem you ran into. Maybe server-side? State persistence is a whole different story. I've found it's hard to do well due to Apollo's ROOT_QUERY combining all pieces of the state. It requires almost an all-or-nothing approach or a lot of hacking to get it to work. I've spent a lot of time searching for proper solutions and even built my own, but they've all been insufficient. Considering local storage persistence brings XSS vulnerabilities as well, I've decided to focus my efforts on performance for now which helps both returning and new users. Personally I love Apollo for its state management and will continue to integrate it in more projects. My biggest gripe at the moment is writing maintainable client-side queries. The code gets quite verbose, especially when you try to do proper (TypeScript) typing without splitting up your code into tiny fragments all over your codebase. And keeping the types in sync with the queries and server-side schema takes a lot of time and effort. I've mostly been thinking about solutions to auto-generate client-side query types, this would increase type-safety as well.

andrewingram 6y ago

That Relay rewrite was over 3 years ago though, and it’s been pretty stable since (the hooks API is coming “soon” but shouldn’t break compatibility). And there was an upgrade path, there was an intermediate compat version which let you incrementally upgrade. The learning curve isn’t that really that steep, it’s just made artificially so by the poor docs. It’s unfortunate that the Relay team doesn’t really prioritise getting new users, because it’d motivate them to explain things better. But there’s not actually that much to learn, you can be up and running and productive with it pretty quickly.

consolenaut 6y ago
True, and admittedly I've only cast a cursory glance over Relay to keep track of where it is every now and again so maybe its unfair of me to write it off quite so quickly. But I think you're also right about the learning curve being made artificially steep by the poor docs, and when you're introducing this stuff to a team who are already new to GraphQL, adding another framework on top with even poorer docs than Apollo is a hard sell

city41 6y ago

Are you sure you like Apollo? I ask because your comment says it's wonderful, but then gives a lot of reasons as to why it's not. I don't like Apollo on the client (no issue with it server side). I feel the sharp edges and pitfalls are numerous and it's a lot of boilerplate to get anything off the ground. To be totally fair to Apollo, I'm also not sure the projects I worked on really needed or benefited from GraphQL on the whole, so...

consolenaut 6y ago
I do on the whole yes, its not something I rave about unreservedly the same way I do about styled-components for example, but its still a tool I'd opt for on projects that actually have a need to do GQL stuff. Its like your favorite screwdriver that you somehow always manage to cut yourself on - you're extremely grateful that you have this tool, it lets you tighten screws even in the narrowest spots, you just wish the handle wasn't so damn sharp

undefinedzero 6y ago

I don't understand the problems you guys are running into with Apollo local state. I've been using Apollo rigorously for 2 years now (though not yet upgraded to v3), and my experience is the state is a blessing. In the past I had to write or figure out my own Redux solutions to store data from queries in the state and now that comes out of the box with Apollo. If I want to manipulate this state locally, I can just do a client.writeQuery in a standard JS function (no resolver bullshit). In the rare event I want purely client-side state, I can use the same method with the @client directive. I've never really needed resolvers as I can contain the logic in my `update` handlers or state manipulation (action) functions that look and behave like standard JS. Caching is great out of the box. You get all variations you might want (cache-first, cache-only, cache-and-network) and it's very easy to configure. Not sure what problem you ran into. Maybe server-side? State persistence is a whole different story. I've found it's hard to do well due to Apollo's ROOT_QUERY combining all pieces of the state. It requires almost an all-or-nothing approach or a lot of hacking to get it to work. I've spent a lot of time searching for proper solutions and even built my own, but they've all been insufficient. Considering local storage persistence brings XSS vulnerabilities as well, I've decided to focus my efforts on performance for now which helps both returning and new users. Personally I love Apollo for its state management and will continue to integrate it in more projects. My biggest gripe at the moment is writing maintainable client-side queries. The code gets quite verbose, especially when you try to do proper (TypeScript) typing without splitting up your code into tiny fragments all over your codebase. And keeping the types in sync with the queries and server-side schema takes a lot of time and effort. I've mostly been thinking about solutions to auto-generate client-side query types, this would increase type-safety as well.