[janic]

I think there actually is an issue with our data models. REST apis have moved a lot of the complexity of data fetching on the client apps since it is basically a 1 to 1 mapping of the database schemas. Making connections between the different data types becomes a frontend concern which is not ideal since frontend has to deal with partial data and full network latency / failures.

Thinking in graphs and query languages like GraphQL makes building for change a lot easier. Your api now defines all the possible data types and their associations (think nodes and edges). This completely eliminates the need to write data management code as a graphql client library can take care of fetching, normalizing and providing the data to components since it knows about the data schema.

Queries can also be composed from fragments which goes very well with the React component model. This allow each component to define the data it needs and then all those fragments can be composed to generate a query. This query will only fetch the exact data it needs for what is displayed wherever the data comes from.

It does move back a bit of the complexity to the backend (defining schema, fetching connections between the different data types) but this is a lot easier to implement since you have full access to all resources. It is also easier to iterate on the implementations since code shipped to client apps can be hard to update when considering mobile apps.

[HenrikJoreteg]

I use graphql extensively as an API for apps I've built this way. But I don't feel like it really fundamentally changes very much in the client (other than much more efficient data fetching). But you still have to compose the data into the view the client is trying to render. Defining data requirements in components is nice in theory, I just personally don't know of any examples where this approach is being used successfully at scale. There may be examples I don't know of. Do you know of any successful large Relay apps?

[janic]

Artsy is a great example since their code is open source https://github.com/artsy/emission. Facebook does use relay in a lot of products. I’ve also seen a talk about how airbnb uses Apollo in a similar way as relay and collocate fragments with components.

If I take the example in your article I think this model solves the problem nicely. Let’s say you want to include a cart component that was created by a completely different team, in another part of the app, all you have to do is to add the fragment to the query that already exist in your screen and everything just works thanks to composition.

Then when someone adds features to the cart and for example fetch the full list of items then all screens that render that cart component will have their query update accordingly since they include the cart fragment.

[cuddlecake]

Probably Facebook, but I'm not entirely sure, since they didn't start with GraphQL but rather created it along the way