[dmitriid]

> With REST you can have an N+1 query, but you're making multiple round trips from the client to the server.

With REST I can specifically optimise the calls because I know the contract and the possible incoming/outgoing requests.

> I can add the field without impacting existing clients that I have shipped. With REST, the old clients would also get the new field.

Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?

One word: versioning

> The point is that your teams can function independently of each other, each focusing more effort on doing their own job & less time syncing with the other team.

Don't blame your failing processes on technology. There's nothing magical in GraphQL that makes it a magical thing making teams independent of each other. Tell me: what happens when frontend team requests data that's not exposed in the GraphQL schema?

[joshribakoff]

> Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?

Why are you discussing graphQL you're oblivious to the problem it solves. Graphql obviates the need to version, like with REST. Facebook had that problem with 30k react components, their processes are fine. My processes are fine too, you are obviously just biased against graphQL. You can specifically optimize a graphQL query by the way.

Versioning creates an explosion of REST end points in fast changing code bases. GraphQL solves that problem. If you don't have that problem then don't use it. You don't need to insult other people who are explaining the benefits it had in their project. That seems oddly defensive of REST, which is the de facto transport for a GraphQL query (they aren't even mutually exclusive). This comment thread is like arguing what is the better fruit apples or potato. And potatoes aren't a fruit

[dmitriid]

> Facebook had that problem with 30k react components, their processes are fine.

Ah. The old fallacy of "if it's good for Facebook, it's good for me".

> Versioning creates an explosion of REST end points in fast changing code bases. GraphQL solves that problem.

So. What happens when you change your GraphQL schema to an incompatible one? Just don't tell me a GraphQL schema is magically perfect from the start.

> That seems oddly defensive of REST, which is the de facto transport for a GraphQL query (they aren't even mutually exclusive).

It's not defensive. It's questions about the reality of things that every and all GraphQL proponents dismiss and brush over.

[joshribakoff]

I did not say that. That's a straw man. If you have the same problem as Facebook it is useful to consider the same solutions. No one is saying that all projects have the same problems as Facebook

You can still technically version a graphQL API just the same as with REST. I haven't heard of anyone having to do this. In practice you add new fields and stop using old ones incrementally.

The biggest benefit is a front end developer can mock up a new UI without waiting on a new backend endpoint. You can a/b test many variations of your UI without a plethora of ad hoc end endpoints

[bmn__]

> Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?

It's on purpose. You can see it how Graphql is marketed in tech meet-ups. The proponents always argue against strawmen. I find it disgusting.