Hacker News new | ask | show | jobs
by deckard1 2310 days ago
GraphQL is mediocre. It's luke-warm mashed potatoes from a chain diner.

Having used it for a number of years now, I still don't know why people recommend it beyond other people recommending it. Out of the box, it comes with no batteries included. Which explains the cottage industry that popped up to support it (Apollo, Hasura, etc.). Simply making GraphQL as efficient as bog-standard REST without involving the use of half a dozen 3rd party libraries is a fool's errand.

Silicon Valley suffers great amnesia and NIH. We've had RPC forever now. XML RPC, SOAP, thousands of others that don't deserve mention. There is a reason people moved from SOAP to REST: you didn't need that complexity. (On a side note, it makes me incredibly depressed to be in this industry knowing how much time and effort died trying to make XML a thing. When was the last time you heard "XML" on Hacker News? Probably been awhile. Maybe 5-10 years now. As a piece of news that is, and not some random comment from an asshole like me.)

Requesting arbitrary pieces of data on the client side (GraphQL's seemingly raison d'etre) is quite easy with REST. So easy that it makes me curious how much brain damage the industry has to think otherwise. Creating new endpoints even? Not a big deal. Not nearly as big of a deal as writing the mountains of boilerplate to get a new GraphQL query up and running. And considering we're talking about GraphQL, it's most likely going to be the same team members working on both sides. Why would that not be the case for REST as well? The mind boggles. All the arguments against REST that GraphQL camp makes are disingenuous at best.

4 comments

Hasura is more than just GraphQL. It maps GraphQL queries to single SQL statements. So you can think of it more as an ORM, but rather than mapping objects to the database it maps GraphQL statements.

The advantage of this over a traditional ORM is that by having the entire query up front it can be smarter about how it does the translation.

Regarding REST, this is very very different. With REST, you map a single "query," the REST endpoint, to an SQL statement (ideally one). But if you want some other query, you're out of luck. Either you make a new REST endpoint, or you manually call several endpoints and compose the data.

There are some dangers to the GraphQL to SQL approach, namely it's harder to guarantee performance when the client can execute arbitrary queries.

Now, GraphQL by itself, I agree it doesn't solve the hardest problems: getting the data for the query and doing it security. But something like Hasura does address those points and I do think it is an advancement over previous technologies.

After using GraphQL with code-generated Typescript types on the response, I can't imagine going back to REST and it's "hope and pray" the JSON looks how you expect it to look
I think part of the actual, non-hyped benefit is that it adds type definitions to incoming and outgoing fields on the client side. Working directly with JSON is kind of fucking awful. Attempts to fix it are often of an even more unpleasant "now you have two problems" sort (JSON-Schema, for example). Any well-supported standard for typing interfaces for data sent to the browser & other REST-consuming clients, even if the underlying transport remains JSON or whatever, is welcome.
> After using GraphQL with code-generated Typescript types on the response

What library are you using to generate the types?

Apollo is more than just GraphQL -- it has built-in caching, and gives you booleans for loading state, and more. If you were to roll your own wrapper around window.fetch, for a simpler facade to work with (when making network requests in React), you'd end up with something like Apollo's interface. And that really useful API surface has nothing to do with GraphQL as a specification.

I used to roll all of this stuff from Redux, with actions, reducers, the whole 9 yards. Apollo let me gut all of that-- since I was only using Redux to store data retrieved over the network. Now I'm not hear to preach Apollo specifically, but it's the only client I've worked with, and I can achieve higher productivity with it than working a lower level.

> Not nearly as big of a deal as writing the mountains of boilerplate to get a new GraphQL query up and running

This is the thing Hasura (and Postgraphile) is trying to make go away. From my limited experience with Hasura, it works pretty well.