GraphQL Query Generator

Post by kevsim » Wed, Jul 22, 2020, 5:58 PM UTC

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…

Post by Varriount » Wed, Jul 22, 2020, 7:29 PM UTC

monadic2 wrote: post #30

Varriount wrote: post #8

Earlier quoted context omitted.

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…

How often do you need to use a join from the client? It's not like "rest" has built-in joins either.

  # REST Call
  GET /hero?primary=true

  # GraphQL Query
  {
    hero {
      name
      friends {
        name
      }
    }
  }

  SELECT
    heroes.name,
    (
      SELECT heroes_inner.name
      FROM heroes AS heroes_inner, friendships
      WHERE friendships.left = heroes.name AND
            friendships.right = heros_inner.name
    )
  FROM heroes
  WHERE name = ? AND primary = true;

Post by allthingsapi » Wed, Jul 22, 2020, 8:45 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 kossae » Wed, Jul 22, 2020, 11:16 PM UTC

philliphaydon wrote: post #24

kossae wrote: post #20

Earlier quoted context omitted.

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.

If you’re the only consumer of your api then why are you exposing more data than you need? I’ve never seen an internal rest api that was 100% restful. It was restLike. So if you have consumers of your api then allowing them to pull only what they need makes sense. But for an api where you are the only consumer, it makes no sense.

Post by rorykoehler » Thu, Jul 23, 2020, 4:59 PM UTC

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…