My view on this may be idiosyncratic and wrong, as I haven’t read about other teams doing this intentionally. Having said that... The most powerful but underus

My view on this may be idiosyncratic and wrong, as I haven’t read about other teams doing this intentionally. Having said that... The most powerful but underused feature of GraphQL is that it abstracts away the details about the BE database model, which is for the FE (i.e., the product and user experience) an unnecessary implementation detail. A poorly designed GraphQL schema (and my teams did a lot of this at first) often look like denormalized REST endpoints. This is particularly true in Relay (do people still use Relay?) In such a case, you’re right that FE-BE coordination doesn’t change much. Additionally, FE stores like Redux are still central to managing derived data necessary for component rendering. However, a well-designed GraphQL schema looks like the shape of data required for component rendering, i.e., for the user experience. Example: having top-level queries for “users” vs. “profiles”. The first has all the data about a user, the second has all the data required to render a user profile page, which almost always includes more data. Let’s say there is a profile photo. A denormalized scheme just defines a "user.profileImage" as an Image type and returns data from a DB relationship of a similar sort (knex and other tools make this easy). While this might seem fine, it is the start of the same old story — BE being blissfully unaware of the use of its data in the context of the user experience. Perhaps when a user has no profile photo a default one should be shown based on their “organization” profile photo. No problem, just pull “user.organization.profilePhoto”? Well, okay, but maybe that is missing too, and we... go down a FE rabbit hole when all we really want is a stupid URL to an image! The alternative I’m suggesting, one that forces FE and BE (ideally one team) to talk about the user experience, is to have a “profile.photo” schema that is resolved on the server. The result of this pattern is a GraphQL schema that accurately describes the user experience. I took the dumbest example possible, but in short, this pushes a lot of complexity to the server where it truly belongs. The FE should be as light, dumb, and functional as possible. The BE should understand comprehensively how their data is going to be used in order to design data models that are efficient. Moving from a denormalized GraphQL schema to a UX GraphQL schema is a liberating experience for everyone involved. The BE cares about the product as much as the FE. This gets them that much closer to the user, where they ought to be. And to your point, this enables the BE to identify potential resolver bottlenecks (and to design for them rather than hacking around them) before such problems ever appear.