Hacker News Reader

Comment by codegladiator | Hacker News Reader

GraphQL is not like REST at all because if something is not defined in GraphQL, it cannot be done. For instance Graphql servers cannot have dynamic fields in models (example aggregate queries)

https://stackoverflow.com/questions/45842544/graphql-objectt...

In REST, I can send the columns and know what I am going to get back. All the queries need not be defined to start with.

View on HN

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.

Reply on news.ycombinator.com