4 ms·

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do nea

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever. Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some composition on top of that? Seems kind of redundant. Like wrapping your own christmas present. But then I realize I'm thinking from the perspective of a one/two person team. Perhaps the real value of this comes from very decoupled consumers.

djmashko2 9y ago
You're in luck, there are libraries that can do it for you! https://github.com/stems/join-monster https://github.com/stems/join-monster And even a system that generates your whole schema: https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql Plus, the Graphcool framework allows you to bring your own DB: https://github.com/graphcool/framework https://github.com/graphcool/framework
- DigitalJack 9y ago
  Holy crap, that's awesome, thanks!
habitue 9y ago
Yeah the benefits are mainly when you have many different consumers all of whom want to look at the data in different ways, or when you have many different data sources in your architecture and want to aggregate them on the fly based on the exact incoming query. If you're writing rest endpoints for an SPA and you have one backing store, then the benefits are not really there, it's just another layer. There are some nice things in relay like intelligent caching portions of the data and only refetching the parts needed, but it is very likely not worth it if you can just handcraft your endpoints and make your consumer change in sync.
orclev 9y ago
I think what you're missing is that GraphQL isn't SQL, but rather a SQL-ish query language that supports a limited subset of what SQL does. Additionally, GraphQL lets the server define the schema that's being exposed to the client independent of the actual storage underneath that, including defining and limiting the types of mutations that can be applied. If you were to simply expose the ability for clients to feed SQL queries into your backend then you have to worry about policing those queries, scrubbing problematic values out of the queries, and in general preventing users from doing bad things with your database. By exposing a GraphQL interface you're providing a limited and tightly controlled view into your data, but still allowing the client the freedom to specify the shape and partitioning of the data being returned.

djmashko2 9y ago

You're in luck, there are libraries that can do it for you! https://github.com/stems/join-monster https://github.com/stems/join-monster And even a system that generates your whole schema: https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql Plus, the Graphcool framework allows you to bring your own DB: https://github.com/graphcool/framework https://github.com/graphcool/framework

DigitalJack 9y ago
Holy crap, that's awesome, thanks!

habitue 9y ago

Yeah the benefits are mainly when you have many different consumers all of whom want to look at the data in different ways, or when you have many different data sources in your architecture and want to aggregate them on the fly based on the exact incoming query. If you're writing rest endpoints for an SPA and you have one backing store, then the benefits are not really there, it's just another layer. There are some nice things in relay like intelligent caching portions of the data and only refetching the parts needed, but it is very likely not worth it if you can just handcraft your endpoints and make your consumer change in sync.

orclev 9y ago

I think what you're missing is that GraphQL isn't SQL, but rather a SQL-ish query language that supports a limited subset of what SQL does. Additionally, GraphQL lets the server define the schema that's being exposed to the client independent of the actual storage underneath that, including defining and limiting the types of mutations that can be applied. If you were to simply expose the ability for clients to feed SQL queries into your backend then you have to worry about policing those queries, scrubbing problematic values out of the queries, and in general preventing users from doing bad things with your database. By exposing a GraphQL interface you're providing a limited and tightly controlled view into your data, but still allowing the client the freedom to specify the shape and partitioning of the data being returned.