5 ms·

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 mo

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-objecttype-with-dynamic-fields-based-on-arguments 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.

philplckthun 6y ago
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.
odshoifsdhfs 6y ago
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?
- codegladiator 6y ago
  Try to build an aggregate API over graphql. Where all sql functions are allowed on appropriate columns.
  - odshoifsdhfs 6y ago
    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)

philplckthun 6y ago

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.

odshoifsdhfs 6y ago

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?

codegladiator 6y ago
Try to build an aggregate API over graphql. Where all sql functions are allowed on appropriate columns.
- odshoifsdhfs 6y ago
  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)