4 ms·
Yes - (and totally reasonable question, btw - it's remarkable how hard it is for the folks behind it to just plainly state what it is vs. coating it in buzzword
by nlh 7y ago
Yes - (and totally reasonable question, btw - it's remarkable how hard it is for the folks behind it to just plainly state what it is vs. coating it in buzzwords).
BTW - I may be wrong / misunderstanding something here as I'm only in the research phase, but here's what I got:
GraphQL is an alternative to REST as a way for clients to query servers for information. In a REST query, you hit an endpoint and add optional query params. But you get back results based purely on what the server has been singularly designed to give back. For example, if I query:
GET /users/1
I'll get back a user object that the server has been programmed to return. It's of course possible to customize this with query params, and do something like:
GET /users/1?only_include=first_name,last_name
But that's the exception to most RESTful APIs, not the norm.
In a GraphQL query, the client specifies _exactly_ which fields it wants back, and that's baked into the design. So the client would submit a query like this:
{
user(id: "1") {
first_name
last_name
}
}
And the server would return exactly the object the client asked for.
There's no magic here -- that's the part that many people have trouble explaining. When you write your GraphQL server, you still need to write the actual queries (<--- this is the key!). But structurally, you write more generic queries -- you'd say "when a client requests a user, run this SQL", "when a client requests first_name on a user, run this SQL", etc. etc.
That way on the server, you write isolated query resolvers (called, amazingly enough, resolvers), each of which get run when a query comes in.
This is as opposed to a RESTful approach, where you'd do a more traditional single SQL query for the /users/:id endpoint (SELECT * FROM USERS WHERE ID = ... )
Hope that makes sense (and is accurate!)
- AndrewOMartin 7y agoYour understanding matches my understanding, but you missed the point which was the "ah ha!" moment for me. Which is that the front end developer can design their own endpoints without bothering the back end developer. When a front end developer wants to request a specific shape of data (e.g. All the people with age between x and y who are within a distance of z of the logged in user and just get their name and list of interests) then with REST they have to either compose that data from the available endpoints or bother a back end developer for a new endpoint. With GraphQL the front end developer can compose the query themselves without knowledge of any back end technology beyond the GraphQL schema. E.g. they'd write something like the following, using either a schema reference, or introspection-powered autocomplete UI to find out which fields are valid. query nearbyCandidates { allUsers(filters{ isTheLoggedInUser:false, ageBetween:{start:x, end:y}, closerThan:{distance: z, from: [LoggedInUserPosition]}, }){ interests:{ interestName:name, description, } candidateName:name, } } This actual story is a bit of a fairy tale because you'd still need the two developers to interact if the required fields or filters did not exist. Finally the general theme of the comments here, that there's nothing stopping you using both, is accurate.
- pier25 7y agoUnless you are using something like Hasura which in many cases negates the need of a backend developer. Front end developers can have almost total autonomy.
- Exuma 7y agoSuper awesome answer, thank you! Im glad you validated what I thought about how insane it is to read about it without drowning in buzzwords so much that I stop reading. Thanks again