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.
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.
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.
GraphQL definitely has its warts, but it provides more flexibility on the API response than you'd get with ReST, so you're neither sending the whole world to keep your API space small nor adding new endpoints to handle each new client use case. But, GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.
Hasura is working to simplify that layer, but developers aren't cheap and I'd imagine the work isn't terribly fun. A lot of existing web frameworks have sprung up out of consultancies to support that development cost. Raising capital is just another funding strategy.
>GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.
This is what I'm struggling with when it comes to weighing the pros and cons of GraphQL. I like the SQL model, ie pushing selects and joins and such to the DB, so why not from client to host too? But when you still need to enforce access restriction and such per user per action, how much time would it save me, really?
Seems great for internal apis or prototyping though.
Hasura and Postgraphile both use row level security for access restriction. Anyone can still execute a query, but they won't get back data they don't have access to.
While doable, you probably don't really want a web client talking directly to your RDBMS, if for no other reason than connection management would be a nightmare. The calculus there might be different if using something like DynamoDB, but I suspect you'd still find it challenging to be littering your code with DynamoDB calls. So, at some point you'd build your own little utility classes to abstract away the DB interaction, much like an ORM, and eventually it'll evolve into something with overlapping functionality of GraphQL.
If you accept that you don't want your web client talking directly to the database, then you need something that will interface with the database. That problem has been around for a while with many different solutions: SOAP, ReST, PouchDB/CouchDB, interface with various cloud services, something completely custom, and many others. GraphQL is just one of the latest solutions to that problem and with it, brings some advantages around flexibility in the API requests and responses. It also makes it easy to stitch together multiple GraphQL APIs. So, by being standardized* you don't need to develop the client code yourself and you gain the ability to pull together APIs from multiple sources to present as a single end-point. The most popular clients also provide caching mechanisms so you don't have to keep whacking the back-end for the same data repeatedly. There's also graphiql [1], which gives you a really nice way to query or modify your data on any GraphQL API, which I've found to be very helpful when learning new APIs.
So far, I've found GraphQL most useful for single page applications where the back-end really doesn't have to do much more than handle DB interactions. If you already have an application up and running with little churn in the API, adopting GraphQL probably wouldn't gain you much. In a greenfield application, I was able to use Hasura to replace a simple Rails CRUD application and that was handy. Hasura also takes care of JWT handling, so I could do my auth with Auth0 and not handle that in Rails either. I think GraphQL solves an interesting part of the serverless puzzle.
Don't get me wrong, GraphQL can be downright frustrating at times. Or at least the popular implementations of it can be. We use Relay at work and while it solves a lot of problems, it introduces many of its own that have cost me hours of frustration. I tried using AWS Amplify on a side project, and having to write new AppSync resolvers with Velocity templates is just not pretty. It really took using Hasura for me to finally be sold on what the GraphQL promise could be (side note: Hasura doesn't support the Relay protocol, so if that's important to you, you'll need to find a different tool).
* -- Standardized is a loose term. There is a GraphQL spec, but it leaves a lot available to implementation details. So, then there are other specs, such as Relay, built on top of that. Or de facto standards based on what the popular clients provide.
As per the article, Hasura is focused on PostgreSQL now. They want to provide a similar experience for other databases also So that they can tap into multiple enterprise customers. Also, I think they are working on features to expose different REST APIs via unified GraphQL API.
It's a big enough problem space I think and it has lot of scope for innovation. Enterprise Integration is also quite a big market, so there is definitely an opportunity to create a profitable company there.
The point made was, software is supposed to solve a problem. Not create a new problem and provide a paid solution. Kinda speaks the truth that something is fundamental isn't made simple yet.
To be fair, some of those are full database engines; they have lots of inherent complexity to tackle.
Hasura provides an interface to a database(/s) engine. GraphQL was supposed to solve the interface problem but it looks like it has created a lot of accidental complexity to tackle.
