GraphQL Query Generator

Post by [deleted] » Wed, Jul 22, 2020, 1:10 PM UTC

hurricaneSlider wrote: post #19

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

Have you looked at Hasura (hasura.io)? Allows you to carefully expose your database as an API, while allowing you to build serverless endpoints for validation, business logic and side effects. Bakes in authorization as a first class concern. There are some other similar alternatives that do much the same. Think it's a mistake to consider GraphQL as a drop-in replacement for REST, writing a vanilla GraphQL server is i…

Post by philliphaydon » Wed, Jul 22, 2020, 1:18 PM UTC

kossae wrote: post #20

philliphaydon wrote: post #14

Earlier quoted context omitted.

But if you’re the only consumer of the api then it doesn’t help reduce data, unless your UI is configured to show different amounts of data. It also doesn’t make network requests faster. I would argue it’s slower when returning the same data between a rest api and graphql. The difference is you don’t do unnecessary joins when you don’t need data. (Since most graphql apis are in front of a relational database anyway)

The idea is that you can select the exact data fields you need for your UI. In a traditional REST-like response, say for a User model, you may receive all data (within authorization limits) about the user in the response when all you needed was the first_name field. With GraphQL you would just receive first_name without the rest of the unneeded fields, thus reducing the amount of data sent.

Post by heelix » Wed, Jul 22, 2020, 1:25 PM UTC

Post by lowmemcpu » Wed, Jul 22, 2020, 1:37 PM UTC

DigitalSea wrote: post #6

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

>Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints? You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spendi…

Post by monadic2 » Wed, Jul 22, 2020, 2:05 PM UTC

Varriount wrote: post #8

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

Although I haven't used it personally, I can see it being very useful for APIs where the "objects" involved contain many fields/relations. Rather than coming up with a limited set of filter/query parameters, you can take advantage of a query language with tooling. That being said, one of the things that irks me about most* GraphQL implementations is that they seem to do joining entirely server-side. This makes sense…