[code_biologist]

My practical experience with that idea is pretty negative, at least with any degree of scale (either in how widely used the resource in question is or in number of people working on the system). I saw a multi-year mess made at a company when the widely used `ResourceA` got endpoints for `ResourceAandB` and C, and D, and E... for the reasons you mention. Then somebody added some fields to make a `ResourceA'` with a specific additional feature. Then somebody removed unused fields from `ResourceA'` for better performance, creating different subsets. We ended up with some `ResourceAandC` things moving to the new `A'`, some features did a frontend join with multiple queries, some things moved to a new superset resource named `ResourceA''`. It was a Cambrian explosion of variants of types. Like violence, it ended up being "if one doesn't work, just add more."

It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.

[jongjong]

> It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines.

I don't buy this argument. Imagine if an airplane manufacturer had the same philosophy. "We can't just substitute that component because it wouldn't fit the existing frame... Oh but wait, we can't just change the frame or the new component to make it fit because of social factors within the engineering team. Let's just tack it on as originally planned and then work around the issue by implementing a complex solution in the software to make up for the structural design flaw.."

That's basically the Boeing 737 MAX story. We know the result of that philosophy.

[dalyons]

Software isn’t nearly as expensive as building airplanes, and the cost of being wrong is infinitely lower. That’s why we build it fast, and iterate quick. It’s not a good comparison.

[dalyons]

This is 100% my experience, and this is a very astute observation :

> It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.

I think people miss the point a lot when ranting about graphql. It’s not particularly their fault, I didn’t get it either until I experienced multiple massive rest messes like you describe.

Also, as social/org tech you don’t really see the benefits in small teams / simple products / small apis. It just feels like extra complexity at that size.