3 ms·

I’m confused about the sell of Graphql as being a more “flexible” API. From the client side it seems great. You basically define what data you want in your quer

I’m confused about the sell of Graphql as being a more “flexible” API. From the client side it seems great. You basically define what data you want in your query, hit 1 endpoint and get said data. If you your data needs change, simply change your query. Or so says most every Graphql blog post out there, handwaving over how a backend would actually handle that. But the reality, it seems, is not that. Now that we’re (finally) getting some posts digging into the backend implementations it’s not clear how the above can be true. AFAICT, the example in the Post is no different than a GET /users (or any other rpc type api). In fact, forcing the client to specify the return fields is completely unnecessary because unless I am missing something, the client is getting all the User fields back every time anyway? I dunno. Maybe I’m missing something. Just seems like implementing a backend to be as flexible as we’re being sold would effectively be writing a schema-aware transpiler from Graphql to your underlying datastore’s query language.

patelpankaj 9y ago
The return fields specify the data you want on creation of resource. In REST, the server used to return either full data or the [201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) Specifying the fields on mutation means data is inserted/updated and the query on the new data has following changes, and you can select form those changes
- krainboltgreene 9y ago
  > In REST, the server used to return either full data or the [201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) Nothing in the dissertation or any other describing document enforces or even suggests you have to do this, and in fact a popular standard gives a means for not doing this: http://jsonapi.org/format/#fetching-sparse-fieldsets http://jsonapi.org/format/#fetching-sparse-fieldsets
nikolasburk 9y ago
You're hitting the nail on the head that implementing the resolvers is the hard part when building a GraphQL server! I work at Graphcool (www.graph.cool) and we recently open-sourced a new tool called Prisma that will help you with exactly that part! Our goal with Prisma is to automatically turn any database into a GraphQL API - right now we have connector for MySQL, but we're working on more for Postgres, MongoDB, Neo4j etc... You're then building your application server using GraphQL bindings (read more here: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...) which allows to simply delegate incoming queries to the underlying Prisma engine. Would be curios to hear your opinion on Prisma! You can try it out here: https://www.prismagraphql.com/docs/quickstart/ https://www.prismagraphql.com/docs/quickstart/ You can also check out the 4min demo-video (with TypeScript) I made that explains how it works: https://www.youtube.com/watch?v=20zGexpEitc https://www.youtube.com/watch?v=20zGexpEitc
- rco8786 9y ago
  Nice! After I wrote that comment my brain gears got turning and I started wondering how I might build something exactly like that.
ruslan_talpa 9y ago
translate from REST to SQL is exactly what PostgREST is doing and you get the same flexibility as with graphql
- bmpafa 9y ago
  I guess we're approaching a sort of Atwood's law for GraphQL. Here's the GraphQL version of PostgREST: https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql
  - thibautg 9y ago
    Postgraphile is very nice because you only need a PostgreSQL and a front-end app with Postgraphile in between. No need to write tiedous middleware functions. And it watches your DB schema and automatically generates a documentation for GraphIQL. Nice piece of software !
joshribakoff 9y ago
The client only gets back the fields requested. Graphql resolvers are tricky but you would have had to coalesce that data somehow, such as on the client. Graphql just provides more structure. It allowed me to replace ad hoc query parameters, coalesce on server instead of client, and no longer need to version my API. If all your app does is fetch one user with two fields like this example it's hard to see the benefit. When you have sprawling backends with a large entity graph it is immensely valuable
bmpafa 9y ago
I've been using GraphQL for a bout a year now on several projects. the 'flexible' part for me comes in more advanced scenarios like: Once I establish a relationship between two entities (`Types`), I can fetch an arbitrary combination of them from my endpoint. e.g., the resolvers that allow me to execute a query like 'fetch all posts by users who signed up since last week' to the same endpoint' can also answer 'fetch the Id of the authors of posts that start with the letter "a",' or even "fetch me every post by an author who's published a post in the past week titled with a word that starts with "C"'. All of these are possible just by defining the relationship b/t `Post` and `User`. The other part I find really something is custom field-level resolvers. Instead of every field corresponding to a database table, the `GraphQL` server can execute arbitrary code to resolve a field. In the `User` / `Post` example, I can add a field called `weather` to `Post`. Whenever the endpoint is returning a `Post` with `weather` included in the response, it could fire an API call to a weather API for the weather at the time / location that post was created. To the API consumer, this is totally transparent and `weather` is returned as though it was already in the database. This sort of arbitrary composition of data types is really at its best with `schema-stitching`. I have a bunch of content in a GraphQL-powered CMS BaaS, and using a few lines of code with `graphql-yoga` (a server), I can combine the CMS schema with a schema for my own custom data model, and even merge the two. e.g., extend my `Post` type in my CMS with a `weather` field from above.
- rco8786 9y ago
  Cool, thanks for your reply and insight. That does sound pretty useful!

patelpankaj 9y ago

The return fields specify the data you want on creation of resource. In REST, the server used to return either full data or the [201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) Specifying the fields on mutation means data is inserted/updated and the query on the new data has following changes, and you can select form those changes

krainboltgreene 9y ago
> In REST, the server used to return either full data or the [201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201) Nothing in the dissertation or any other describing document enforces or even suggests you have to do this, and in fact a popular standard gives a means for not doing this: http://jsonapi.org/format/#fetching-sparse-fieldsets http://jsonapi.org/format/#fetching-sparse-fieldsets

nikolasburk 9y ago

You're hitting the nail on the head that implementing the resolvers is the hard part when building a GraphQL server! I work at Graphcool (www.graph.cool) and we recently open-sourced a new tool called Prisma that will help you with exactly that part! Our goal with Prisma is to automatically turn any database into a GraphQL API - right now we have connector for MySQL, but we're working on more for Postgres, MongoDB, Neo4j etc... You're then building your application server using GraphQL bindings (read more here: https://blog.graph.cool/reusing-composing-graphql-apis-with-graphql-bindings-80a4aa37cff5 https://blog.graph.cool/reusing-composing-graphql-apis-with-...) which allows to simply delegate incoming queries to the underlying Prisma engine. Would be curios to hear your opinion on Prisma! You can try it out here: https://www.prismagraphql.com/docs/quickstart/ https://www.prismagraphql.com/docs/quickstart/ You can also check out the 4min demo-video (with TypeScript) I made that explains how it works: https://www.youtube.com/watch?v=20zGexpEitc https://www.youtube.com/watch?v=20zGexpEitc

rco8786 9y ago
Nice! After I wrote that comment my brain gears got turning and I started wondering how I might build something exactly like that.

ruslan_talpa 9y ago

translate from REST to SQL is exactly what PostgREST is doing and you get the same flexibility as with graphql

bmpafa 9y ago
I guess we're approaching a sort of Atwood's law for GraphQL. Here's the GraphQL version of PostgREST: https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql
- thibautg 9y ago
  Postgraphile is very nice because you only need a PostgreSQL and a front-end app with Postgraphile in between. No need to write tiedous middleware functions. And it watches your DB schema and automatically generates a documentation for GraphIQL. Nice piece of software !

joshribakoff 9y ago

The client only gets back the fields requested. Graphql resolvers are tricky but you would have had to coalesce that data somehow, such as on the client. Graphql just provides more structure. It allowed me to replace ad hoc query parameters, coalesce on server instead of client, and no longer need to version my API. If all your app does is fetch one user with two fields like this example it's hard to see the benefit. When you have sprawling backends with a large entity graph it is immensely valuable

bmpafa 9y ago

I've been using GraphQL for a bout a year now on several projects. the 'flexible' part for me comes in more advanced scenarios like: Once I establish a relationship between two entities (`Types`), I can fetch an arbitrary combination of them from my endpoint. e.g., the resolvers that allow me to execute a query like 'fetch all posts by users who signed up since last week' to the same endpoint' can also answer 'fetch the Id of the authors of posts that start with the letter "a",' or even "fetch me every post by an author who's published a post in the past week titled with a word that starts with "C"'. All of these are possible just by defining the relationship b/t `Post` and `User`. The other part I find really something is custom field-level resolvers. Instead of every field corresponding to a database table, the `GraphQL` server can execute arbitrary code to resolve a field. In the `User` / `Post` example, I can add a field called `weather` to `Post`. Whenever the endpoint is returning a `Post` with `weather` included in the response, it could fire an API call to a weather API for the weather at the time / location that post was created. To the API consumer, this is totally transparent and `weather` is returned as though it was already in the database. This sort of arbitrary composition of data types is really at its best with `schema-stitching`. I have a bunch of content in a GraphQL-powered CMS BaaS, and using a few lines of code with `graphql-yoga` (a server), I can combine the CMS schema with a schema for my own custom data model, and even merge the two. e.g., extend my `Post` type in my CMS with a `weather` field from above.

rco8786 9y ago
Cool, thanks for your reply and insight. That does sound pretty useful!