3 ms·

GraphQL is not a query language for your database, it's more like a query language for your REST API. So asking how to do a join in GraphQL is like asking how

GraphQL is not a query language for your database, it's more like a query language for your REST API. So asking how to do a join in GraphQL is like asking how to do a join in REST. It's not a well-formed question. The good news is that the sever can expose absolutely anything as a GraphQL query. They're just arbitrary entry-points into the schema. Think of it as like calling a stored procedure. The procedure is an opaque thing as far as the caller is concerned.

ruslan_talpa 10y ago
You are dismissing a valid question and incidentally this is the question that exposes a problem of the graphql-js implementation (specifically the execution module) when the data source is a database (which 90% of the time it is), though it's not a problem of the GraphQL . Of course he can not "well-forme" it since he is just looking into GraphQL. What he is looking for actually is this https://github.com/stems/join-monster https://github.com/stems/join-monster but it's not without it's problems. PS: My comment does not mean the reference implementation is bad, it's just that it's a reference and good in a lot of cases but not in all. It does not mean you have to use every part of it, you can write your own execution module.
tooFastFuckYou 10y ago
It's a totally legitimate and well-formed question. What is the point of using GraphQL if you're still implementing every query on both the server and the client? I thought GraphQL was some way of abstracting the database so that you could isolate your query logic in the client. That logic is going to require joins in a great many applications. The big pain in the ass of writing a client/server app is keeping the queries in sync between the server and the client, from the parameters for the query itself to deserializing the result. How does GraphQL alleviate this, and if it doesn't, what are we gaining? Thanks for any insight.

ruslan_talpa 10y ago

You are dismissing a valid question and incidentally this is the question that exposes a problem of the graphql-js implementation (specifically the execution module) when the data source is a database (which 90% of the time it is), though it's not a problem of the GraphQL . Of course he can not "well-forme" it since he is just looking into GraphQL. What he is looking for actually is this https://github.com/stems/join-monster https://github.com/stems/join-monster but it's not without it's problems. PS: My comment does not mean the reference implementation is bad, it's just that it's a reference and good in a lot of cases but not in all. It does not mean you have to use every part of it, you can write your own execution module.

tooFastFuckYou 10y ago

It's a totally legitimate and well-formed question. What is the point of using GraphQL if you're still implementing every query on both the server and the client? I thought GraphQL was some way of abstracting the database so that you could isolate your query logic in the client. That logic is going to require joins in a great many applications. The big pain in the ass of writing a client/server app is keeping the queries in sync between the server and the client, from the parameters for the query itself to deserializing the result. How does GraphQL alleviate this, and if it doesn't, what are we gaining? Thanks for any insight.