[realusername]

I don't think it would hold true for very long, devs will have specific cases which will pile into the definitions.

That's why GraphQL examples usually focus on querying data from users and not how you are going to manage 10 different views of the same data.

[hansonkd]

> pile into the definitions

That is how REST works but is the opposite of the way GQL works.

You don't pile into existing defintions but extend the current definitions out. A team needing new data doesn't affect the consumption of other teams. which is not the case of REST where if one team needs to change a REST endpoint to return different shape of data, they have to verify the new shape with other teams.

[realusername]

With REST, the endpoints are team based if you have even a semi-competent CTO so you never have this problem, you just check who owns the controller and that's it.

With GQL though, good luck retracing who owns what field and what does it affect if you change the definition of what it returns, especially that you you are not even using it on the same language.

Bonus points here if you are managing something outside of your control like a mobile app.

[hansonkd]

GQL you would only care about if someone removed a field not if someone added a field. How would adding a field change existing GQL calls return? Doesn't make sense.

Also, Its about 1 line to set up CI to extract all GQL queries from a typescript project and do static analysis to check against the schema.

But again you only care if someone deletes a field, and even if you have to delete it, at least the GQL schema has built in annotations for deprecation, something not in REST.

[realusername]

Deleting things happens all the time though.

Yeah sure you can make it work with anything if you spend the extra effort but the ownership really isn't as defined as in REST.

Is there code which have fuzzy or no ownership? Are there changes which affect other teams? Suddenly those became much harder questions to answer.

[hansonkd]

Actually deleting happens rather rarely compared to adding.

Its much easier to trace and debug what teams are using GQL fields than REST. What if one team is piggy backing on another teams exising rest endpoint and you dont know? same problem that would require some analysis of all code calling and endpoint to determine if a field is safe to delete. GQL makes this much simpler than REST.

[realusername]

On one side you need to check which folder you are in, on the other side you need to do a static analysis of the whole current and past apps.

I know there's some diverging opinions here but there's one which sounds definitely easier than the other.

As for deletes, I work in a company with a good hundred devs so that happens weekly at least.