I created a no-code tool that could do joins, filters, and more with GraphQL, so I really don't see your point. You just need to do it a bit differently (same as REST, and if you follow REST 100%, good luck with n*m calls when you want to join two resources that you don't know from the start):

GET clients [client 1, client 2]

for each client

  GET business (id = client.id)

Now think you can join with business, jobs, invoices, employees, etc etc, and tell me how to do this in rest without basically recreating a query language?

Try to build an aggregate API over graphql. Where all sql functions are allowed on appropriate columns.

I did, the same way you would do with a REST API. you specify a format for a field (in my case, the 'where' and 'join' where JSON structures that you passed as parameters)

Then you write the resolvers that parse that. Pretty much as I would expect you to do it in REST.

(mentioned it in another post, I created a no-code tool that did this, for random data and entities created by the user per tenant/app, so I know the issues with GQL, but I can assure you, doing the same with REST was 10 times harder (api started as REST and moved to GQL after 6 months)

That’s a pretty misleading statement, since what you’re linking to does describe how using scalars can help.

Especially if the scalar never includes other data from the graph (other objects) describing the custom format with scalars is just fine.