Hacker News Reader

Comment by honkycat | Hacker News Reader

A problem doesn't stop existing because you decided to ignore it.

GraphQL solves a very real problem. You need a way to sparsely grab information from multiple resources without having to make a dozen requests on the front-end.

Additionally, you need a standardized way to apply schemas to APIs. Also, you need a way to communicate to your clients how to interact with your API.

GraphQL solves these problems and more.

Comparing GraphQL to Rest is like comparing Rust to C and saying: "You don't need Rust. Memory safety isn't a realistic use case in the real world. Just allocate your memory and use it."

View on HN

That is not really a fair comparison. Rust adds on top of C. GraphQL adds but also removes a lot of nicest things about REST. http caching is the most obvious loss as well as any control access through a middle layer. You are also giving access to the user for a lot of power to make complicated and slow queries, against which protecting yourself is not always easy whereas having API quotas is trivial. A simple graphQL is easier and nicer to use than a easy REST, but as soon as it gets more than that you are trading facilities in the frontend against a huge headache in the backend.

One of my problems with GraphQL APIs is that the consumption of that API because really difficult for simple tasks. With a traditional API wrapper there will usually be a fetchResource() function that wraps the API call for getting a resource with function parameters mapping to HTTP query parameters usually.

With GraphQL I need to look up what specific query I need create to fetch a specific resource. It makes it harder to build quick, one off tools and scripts. Using GitHub's GraphQL API is what I specifically have in mind while I'm typing this.

I think the GitHub GraphQL API docs are particularly badly organized and basically show the API as a bucket of stuff, rather than as CRUD entities (which is how it's actually organized). I don't think this a GraphQL issue.

You have the exact same amount of work regardless of the two, which is reading the documentation. At least with GraphQLi, I can write a query with the docs open and iteratively explore.

Anecdotally, the experience is much easier when it's a REST API. If all I want is to fetch one object and its metadata... then I look up the function and call it.

If it's graphql then I have to... well, step one I have to learn the query language. And then I have to construct the query to return the data. It's not, like, super hard to go through all of that but it's extra cognitive burden that I don't want to deal with.

I'm currently writing CLI tools in Go and have to use the graphql API for github because it offers data that the REST API does not (I think). I really prefer the REST API wrapper.

I am on my fourth rewrite on my in house web application. I am using ruby’s Sinatra with react as the front end. Including graphql in my front end and back end was easy. Querying the api was made easier with the “GraphiQL” app

> If all I want is to fetch one object and its metadata... then I look up the function and call it.

... it's literally the exact same thing for GraphQL. I open up GraphQL explorer, look at one root query I'm interested in, and fire off a request. It's really no different a workflow in Postman/Insomniac if I'm working with a GraphQL or REST API.

The essay is not arguing that GraphQL does not solve a problem, but pointing out that it can be misapplied.

If you do not need to, as you say, "sparsely grab information from multiple resources", but have relatively fixed fetching needs, GraphQL is actually a bad fit. (The essay made this point slightly differently.) Additionally, there are other solutions to the schema problem.

Reply on news.ycombinator.com