On: REST vs. GraphQL – A search for evidence on which is better

[valenterry]

> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything

Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world.

However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments in just one query, so it's much more easy to detect and optimize for that case.

For me, GraphQL wins here.

[fastball → valenterry]

I don't know, I still think you're much more likely to have a frontend dev get annoyed by having to kick off 20 requests (and seeing that perf impact in their own devtools) and ask backend to give them an endpoint that can get all the content in one go.

[valenterry → fastball]

Maybe, but is it really a good idea to rely on the laziness of developers and hope they give you feedback? I've not seen this work out well so far.

[fastball → valenterry]

To my mind, a system architecture that does not take into account is the flawed one, not the other way around.

[valenterry → fastball]

Taking into account is one thing, but relying on lazyness... I don't know, I'm not convinced

[fastball → fastball]

*does not take human nature into account

[reactordev → valenterry]

Same. This is why I was looking for concrete examples because the problem isn’t a graphql problem, it exists in any interface. Kinda a trick question, but it was good reading people’s reasoning ;)

[baumandm → reactordev]

I agree with GP as well, but I do think there are unique circumstances with GraphQL.

One difference is that if the front-end makes N+1 REST calls, it's (hopefully) obvious to the front-end developer. It's also generally easy to map the REST requests to the database queries being made.

Swap it all out for a single GraphQL query and now you have no idea how it will perform or whether it was optimized for the specific fields you are requesting.

Another difference is that REST-style solutions won't work for GraphQL. Imagine you're making a bunch of REST calls, e.g. querying for a list of articles then querying for a list of comments for each one. You can ask the backend team for a new endpoint that returns them all in one query, easy enough.

But with GraphQL schemas, the potential graph of data is too large to write custom SQL queries that efficiently fetch everything in one batch. For example:

  {
    articles {
      title
      contents
      author {
        name
        articles {
          title
          contents
          comments {
            content
            author {
              ...
            }
          }
        }
      }
      comments {
        content
        author {
          name
        }
      }
    }
  }

Maybe a bit contrived, but it illustrates my point. Due to the ability to traverse relationships it's much easier to find yourself in a situation where the implementation of the GraphQL resolvers is not ideal for the usage, but it theoretically will work.

[valenterry → baumandm]

The GraphQL equivalent to creating a new, specialized REST route would be to create a new, specialized query.

E.g. the following REST

    /articles-with-comments?number=20

which returns title, contents etc. would map to a completely new query in graphql

    articlesWithComments(number: Integer) {
      title
      contents
      ...
    }

so it is exactly as easy to optimize. Of course this is not very composable, but that is equally true for both solutions.

[reactordev → valenterry]

and this is the pattern we see in the wild mostly.

[Aeolun → baumandm]

Apparently you could solve this using the dataloader pattern/library.

Every layer would send off one query, unless they’re dependent on each other, but it’d be a far cry from N+1