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
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.
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.
deckard1|6 years ago
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.
tensor|6 years ago
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.
markhalonen|6 years ago
JMTQp8lwXL|6 years ago
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.
vosper|6 years ago
This is the thing Hasura (and Postgraphile) is trying to make go away. From my limited experience with Hasura, it works pretty well.
nirvdrum|6 years ago
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.
jayd16|6 years ago
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.
bdcravens|6 years ago
pritambarhate|6 years ago
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.
crubier|6 years ago
imvetri|6 years ago
bdcravens|6 years ago
SteveBash|6 years ago
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.
imvetri|6 years ago