[seanalltogether]

> When asked most developers say its because you can limit which fields you query

For me this is one of the biggest headaches I have with a new app I've been assigned to. By allowing all fields to be optional depending on the graphql query, there's no consistency in the objects floating around in your apps data store. When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.

Maybe its better when every single page has to request it's own data, but when the model objects are cached to a data store in an app and shared between views, things get really dicey.

[atombender]

A large part of GraphQL is the idea of tightly coupling queries to code, declaratively, combined with smart differential logic.

The original web framework for GraphQL was Facebook's Relay, which essentially lets you declare, in your component, what data you want. Relay stitches together your query and avoids work by figuring out the difference between what data the client has (in its cache) and hasn't.

Apollo's React framework is based around the same ideas. You're supposed to declare the query privately in the component that needs it, and in principle, caching should avoid many unnecessary fetches. For example, if you have:

  // In component A
  {
    currentUser { id, name }
    topStories { id, title }
  }

  // In component B
  {
    currentUser { name }
    favouriteTopics { id, name }
  }

then the delta from A to B is { favouriteTopics { id, name } }, and no re-fetching of currentUser is needed, since it is a subset that merely needs to be filtered.

(There are of course ways to write queries that will always conflict with each other, e.g. by applying different parameters such as filters to nested fields.)

In practice, I'm not sure if Apollo is that smart yet. I think it currently considers any difference in field selections to be a conflicting change, even strict subsets, but I could be wrong.

When used outside of React, GraphQL becomes more like SQL:

  for (const {name} of (await query(gql`{
    users { id, name }
  }`)).users {
    // ...
  }

[lstamour]

Theoretically, a smart enough GraphQL front-end could recognize multiple filters and do some or all of the filtering client-side, or if impossible, request both from the server. The idea that your client can declare what data it needs rather than leaving it up to the server is the best part of GraphQL, the thing that simplified it the most. But it’s hard to do well, right now. It’s much easier to use code-gen directly to have client and server share knowledge of what’s needed. HTTP2 push adds an interesting twist though, when your GraphQL response could actually trigger additional client code and resources to be sent. Of course this can be done without GraphQL, but you’d still need a server that’s aware of what data the client will use and how. For simple APIs or APIs with many clients that behave the same way, GraphQL is overkill. But even so it’s an interesting alternative to simple REST and simple state management, and unlike Redux, you can trigger multiple events at the same time which can be beneficial if processing their state changes at the same time would lead to a more efficient update. (The Redux alternative is to add some kind of wrapper event, or an event for each combination of events...)

[pferdone]

> When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.

Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.

[seanalltogether]

I theory yes, but in practice react native development seems to be a grab bag of 3rd party libraries and design patterns. Redux, apollo, some typed objects, some untyped objects, stateful wizard views, stateless normal views. Maybe your objects are defined and queried on the view you are looking at, maybe they came from a previous view.

[pferdone]

I‘m not talking about theory here but about my professional experience using GraphQL and Apollo for two years in production code. To be specific: I would hardly have a use-case for Redux when apollo-client already has built in local state handling capabilities. Throw in TypeScript and generate your type interfaces from your schema and your queries and there‘s no second guessing. GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together.

[LargeWu]

"GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together."

When you say this, I hear "Apollo and GraphQL are fragile technologies that don't play well with others."

Furthermore, technical decisions like which libraries to use are many times not at all related to technical reasons like this, but rather what a particular developer with influence wants to do, based on their own personal preferences. OR, the downsides of decisions to use certain technologies are often not understood until problems begin to creep up, and by then it's too late. Of course, technology companies, especially venture backed ones, don't want to highlight those things to decision makers. Either way, I have a hard time blaming the rank and file developers who probably had no input in the first place.