> Because the "frontend" might be a native application that can't be updated on the fly and would break when the query changes out from under it.
From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps.
Backwards compatibility and API versioning strategies can easily handle this kind of situation.
> From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps.
Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability.
What's more, if we just offer a set of pre-baked queries, there's no way to measure how many clients are actually using a given column in the query. If we're the developer of both the frontend and backend then we can try to keep track of it internally, and rev the identifiers with each change so we can determine when a given query is no longer being used by any clients. But this requires a lot of bookkeeping internally (e.g. your mobile team bothers to let you know that they're no longer using a given column) and doesn't work at all if you're vending this API to third parties.
If you vend a view, then you could track which columns of your view are actually being used by queries, and once a given column is no longer being used by anyone you can remove it (e.g. because you added a new column that obsoletes it). Though there's no formal way to deprecate the column in order to move people off of it, so that's a step backwards from GraphQL.
> Which is precisely one of the reasons GraphQL exists, so you can change the data queryable in your API without changing the data existing clients receive. If we're talking about moving from GraphQL to SQL then we shouldn't be throwing away this capability.
If you many different clients consuming the API then yes it makes sense.
But if you have only one client (usually a modern frontend or a mobile app) and you can deploy client+backend at the same time, than you don't need that anymore.
You can't deploy a mobile app at the same time as your backend. Even if publishing a mobile app update was instantaneous, it takes time for people to update, and some people never will.
> Backwards compatibility and API versioning strategies can easily handle this kind of situation.
From experience using Wildcard API (a super easy RPC implementation [1]), you usually don't need to do API versioning at all. Instead you always deploy frontend and backend at the same time.
If you have more than one client consuming the API this can get tricky though and then API versioning is necessary.
From my experience that would be an extremely naive decision to make: change the underlying behavior of an API endpoint with disregard for its impact on client apps.
Backwards compatibility and API versioning strategies can easily handle this kind of situation.