The difference is that you'd have to have very smart query builder on the front end side that would construct one sql query from combined declared needs of all the front-end components on one page. Then after it gets response (flat as is usual with sql) it would have to split it up and feed to all of the components.

On the backend you'd probably need sql query analyser that would figure out which tables and rows query touches to determine if currently logged in user should be able to see this data.

So on frontend you need a language in which components can specify their needs (why not graphql?). Next step is asking youself why flatten those to sql before sending them to server only to have it parsed again by the server. It's easier to pass them as grqphql and let server decide if it should respond and draw from data source (or possibly multilple data sources, for example solr and database).

Congrats, you invented graphql. Too bad nobody came up with that 15 years ago, this could save a lot of people a lot of trouble.