[rtpg]

I think the public/private distinction here is more in "officially allowed for public use" vs "API your frontend uses but is not documented for public use". Obviously security is still a thing, but having good ergonomics for your frontend devs means your frontend devs can just work forward and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs

[troupo]

> and backend people can focus on other things instead of going back and forth on perf issues downstream of REST APIs

Instead they now focus on perf problems of downstream federated GraphQL queries. And query complexity. And unbounded queries. And extreme overfetching of data that all clients inevitably do. And...

[rtpg]

If anything REST APIs encourage overfetching, because you are almost never getting exactly the set of data you need.

Unbounded queries and extreme overfetching in general are problems that are ... easy-ish to solve when it's totally internal. Just be measuring perf, tag queries you are making to the frontend page you're making them from, and coordinate with frontend people if there's a problem.

Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either. There might be patterns that are dangerous in GraphQL but honestly I feel like most internal APIs would benefit from easier scoping of fields and the like (rather than everyone re-inventing ad-hoc expansion and filtering)

[troupo]

> Performance doesn't magically improve if you're using REST. And joins don't magically make things slower than "join via HTTP request" either.

In REST you know the exact query and can optimise the hell out of it. Not so in GraphQL, where each query is potentially a new, never before seen request. Unless you use and optimise for persisted queries which just makes it REST with extra steps. And for large companies even that may not be an option since every query will end up being a persisted query once you deploy to production.

[rtpg]

If your UI needs A and A.B and A.B.C, then you end up with three rest queries. Or you end up with some expansion logic. Meanwhile your REST query will likely also be throwing along for the write A.D, A.E, A.F, and maybe A.G.H because of some auto-expansion.

> Unless you use and optimise for persisted queries which just makes it REST with extra steps.

GraphQL offering a syntax and a way to state exactly what will be used makes it possible to chip away what is sent over the wire in persisted queries. This is not a negligable thing in environments with very wide and deep data models. These are places where their "REST" queries end up with "GraphQL with extra steps" through path inclusion/exclusion logic and expansion logic.

Obviously at the end of the day context matters most, but there's been loads of places and APIs I've used where you could feel REST causing performance issues in an end-to-end way, either by generating N+1 HTTP queries, or just shipping way too much data to show a list of names of resources.