alt Hacker NewsI'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library.
The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not.
Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> ResultType"
In a REST API you might have
app.GET("/user", getUser)
app.POST("/user", createUser)
{
"getUser": getUser,
"createUser": createUser,
}
The arguments and output shape of your API routes are typed, like in OpenAPI/OData/gRPC.
That's all GraphQL is.
Replies
This seems a bit reductive as it skims over the whole query resolution part entirely.
This is a great explanation of what the intent of GQL is. I'm curious though, as someone who has only a small amount of experience with it, what problem is that solving? From what I can tell, it's the same problem REST solves with a different interface. If it is the over-fetching problem, how big is that problem?
In my experience, it's better to fix a bad endpoint and keep all the browser/server side tooling around tracing requests than to replace all that with a singular graphql endpoint. But curious to hear someone else's opinion here
GraphQL is best if the entire React page gathers all requirement from subcomponents into one large GraphQL query and the backend converts the query to a single large SQL query that requests all the data directly from database where table and row level security make sure no private data is exposed. Then the backend converts SQL result into GraphQL response and React distributes the received data across subcomponents.
Resolvers should be an exception for the data that can't come directly from the database, not the backbone of the system.
I think you're oversimplifying it. You've left on the part where the client can specify which fields they want.
Is this relevant to the posted article? I don't see how the OP misrepresents anything about GQL.
Except you can't have ie. union as argument, which means you can't construct ie. SQL/MongoDB-like where clauses.
As someone who’s used GraphQL since mid-2015, if you haven’t used GraphQL with Relay you probably haven’t experienced GraphQL in a way that truly exploits its strengths.
I say probably because in the last ~year Apollo shipped functionality (fragment masking) that brings it closer.
I stand by my oft-repeated statement that I don’t use Relay because I need a React GraphQL client, I use GraphQL because I really want to use Relay.
The irony is that I have a lot of grievances about Relay, it’s just that even with 10 years of alternatives, I still keep coming back to it.