7 ms·

Thinking in GraphQL

100 points by bholdr 11y ago

pramodliv1 11y ago
We're building a single page app with all the rendering done on the client(clichéd, yeah) and a RESTish Dropwizard API server We have a page which requires integrating data from 12 different REST APIs. Making 12 HTTP requests takes a lot of time. So the obvious solution is to merge the APIs on the server and make a 'business' API specific to that page. But we did not want to repeat all the merging logic on the server during launch. To alleviate the problem, I created a dependency graph/DAG for all the 12 APIs and fired HTTP requests concurrently at each level instead of using 12 promises which increased performance significantly. Does GraphQL support such use-cases?
- leebyron 11y ago
  GraphQL is designed for exactly this use case
WimLeers 11y ago
This does not explain how the client-side cache is kept up-to-date. Cache invalidation matters. You want instantaneous updates on the client if the data has been updated on the server. E.g. What if the like count has been updated? Curious what solutions GraphQL offers for this. If it doesn't solve this itself, then what do GraphQL apps do today to solve this?
- ollysb 11y ago
  Facebook does have an internal solution for push updates, I believe they use long http requests. There were some talk of relay adding support for updates via websockets, anyone have any information?
  - WimLeers 11y ago
    Interesting; I'd love to read _what_ exactly they send in those long HTTP requests. I'd think something along the lines of Surrogate Keys/Cache Tags would make sense: - https://www.drupal.org/developing/api/8/cache/tags https://www.drupal.org/developing/api/8/cache/tags - http://info.varnish-software.com/blog/advanced-cache-invalidation-strategies http://info.varnish-software.com/blog/advanced-cache-invalid... (ugh, they broke their site, cached at https://pinboard.in/cached/a31c4630dd2d/ https://pinboard.in/cached/a31c4630dd2d/) - https://www.fastly.com/blog/surrogate-keys-part-1 https://www.fastly.com/blog/surrogate-keys-part-1 - https://blog.cloudflare.com/introducing-a-powerful-way-to-purge-cache-on-cloudflare-purge-by-cache-tag/ https://blog.cloudflare.com/introducing-a-powerful-way-to-pu...
    - sanderjd 11y ago
      Woah, thanks for those links. All very useful.
- estefan 11y ago
  There's been some mention of supporting subscriptions, but I haven't heard anything about implementation. I think it's on their roadmap.
gldalmaso 11y ago
Details about the backend are often vague or missing in every article that covers GraphQL that I've read so far. Where are guidelines to implement it? How do we make our existing business code integrate with it? How do we make sure a client cannot access data from another client? Does it work well or at all with relational databases? Is the backend a second-class citizen in this approach?
- estefan 11y ago
  There are several implementations. There's a reference in javascript based on express, sangria for scala, and I read on a blog post about people working on a ruby server. See: http://facebook.github.io/react/blog/2015/09/14/community-roundup-27.html http://facebook.github.io/react/blog/2015/09/14/community-ro... You basically define the schema, and for each method you want to support you implement pulling the data from your datastore. Authentication is up to you - stick a bearer header on your requests and implement checks in your server and you have secure backends, etc.
- verbin217 11y ago
  https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js Just implement resolve.
  - xtrumanx 11y ago
    If you have two fields in a query, does that mean two resolve functions? If I using a SQL database and the two fields were stored on two columns on the same table, wouldn't that cause 2 SQL queries to be run?
    - verbin217 11y ago
      Yes. But only one http request. If they're both the same query but access a different field you might be able to cache it.
    - devit 11y ago
      Sangria in Scala has a mechanism called "Deferred" that lets you specify that it should ask you to resolve objects of a certain type all at once at the end, and you would do a single SQL query per object type there. If the JavaScript implementation doesn't have something like this, perhaps it can be hacked on top.
aikah 11y ago
Too invasive. GraphQL actually needs to be implemented on the server, which is a no go for me. The client should not dictate what the server api should look like. I understand it works for Facebook and it's fine, however this thing is so hyped right now developers are jumping into this and promoting this without actually talking about the drawbacks of this tech. And POST requests everywhere? excuse me but it throws away any "natural" http caching. To me it is another example of something that may benefit a project that has 500 million daily users , that is useless for 99% of projects out there, yet is advertised as a silver bullet that will make a poorly optimized app magically scale.
- hippich 11y ago
  I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint
  - fernandotakai 11y ago
    the only problem is that, right now, there's no good lib that you can put on top of your existing infrastructure (for example, django's orm) that can translate graphql -> your-thing. i've been trying to write something like that, but it's kind of awkward, specially because the whole relay stack is not 100% feature stable.
    - hippich 11y ago
      this is official reference lib - https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js you need to implement resolve method to map properties to your backend(s) yes, it is not drop in, but using any node.js http request library should do the trick. also, both can co-exist if you have application which already uses existing rest api layer.
  - aikah 11y ago
    > I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint It is exactly what I'm saying. It's yet another layer on the server, it doesn't solve caching issues, and it will certainly not make your average app faster, especially when http2 support is here. GraphQL is an ORM for rest apis. I thought rest apis were supposed to be universal, why need another layer on top of it? How many ORMs do developers need ? how much more complex does it have to get? The goal of REST is first and foremost readability and simplicity. The purpose of fat clients are to push complexity on the client. With graphQL simplicity is gone since everything is POST thus no http caching, and the server now gets another layer of complexity instead of being client agnostic. Again, it might make sense at Facebook scale, but many articles promoting GraphQL are not talking about the fact that, it might not make sense for the majority of applications out there, even worse, it actually might make apps slower because of that extra layer.
deleted 11y ago
[deleted]
xtrumanx 11y ago
I'm a big fan of React but it took me a year after its introduction for me to get it and like it. What particularly did the trick for me was one of Pete Hunt's talks he gave a year after release acknowledging the confusion and explaining the reasoning for React rather than just the technology itself. I feel like GraphQL can be something great and the pain points they identify with typical APIs are stuff I've felt but GraphQL just feels incomplete to me. I feel they're focusing too much on what GraphQL looks like on the client-side and not enough what it looks like on the server-side. The biggest question I have is what's going to process the GraphQL query on the server to fetch the data from the actual datastore? What does that look like when working with typical datastore such as a SQL-based database? The closest thing I've seen that answered that question was this blog post[0] which doesn't look very appealing if that's what the server-side implementation is going to look like. The blog post's implementation looks like a more complicated version of my own APIs which are usually a series of custom endpoints based on my client's needs. I don't see the big deal right now. Maybe next year... [0] https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2 https://medium.com/@clayallsopp/your-first-graphql-server-3c...
- estefan 11y ago
  Check this out if you understand scala: https://github.com/sangria-graphql/sangria-akka-http-example https://github.com/sangria-graphql/sangria-akka-http-example Pulling data from a datastore is up to you. You can use whatever library you like to pull data in. All you have to do is make your `resolve` methods just return the data. The GraphQL schema definition is basically an adapter (as in adapter pattern) on top of your datastore(s).
- insin 11y ago
  I found this example in the dataloader README useful, as it deals with loading from a SQL-based database, with relationships, which is similar to the first project I'm planning on trying it with: https://github.com/facebook/dataloader#using-with-graphql https://github.com/facebook/dataloader#using-with-graphql
- dustingetz 11y ago
  GraphQL means UI components can stand on their own - they work without custom endpoints. And it's faster. You do need to write an adapter between GraphQL and your datastore, which is probably hard today, and probably easier next year, but you only need to pay that cost once.
MehdiHK 11y ago
I'm writing a series on learning GraphQL here, if anybody is interested: https://github.com/mugli/learning-graphql https://github.com/mugli/learning-graphql
owyn 11y ago
All the examples I've seen so far have a "hardcoded" schema expressed in code. Besides code generation, is there some way to express a schema in another format? Is anyone working on a way to define dynamic schemas? For example, a user defined schema rather than a developer defined schema. What I'd really like to see is a tool/library/framework to create a graphQL schema, store it in a database along with the data, and efficiently query the whole assembly. I'm thinking of something like Semantic Mediawiki that isn't terribad. :)

100 points by bholdr 11y ago

We're building a single page app with all the rendering done on the client(clichéd, yeah) and a RESTish Dropwizard API server We have a page which requires integrating data from 12 different REST APIs. Making 12 HTTP requests takes a lot of time. So the obvious solution is to merge the APIs on the server and make a 'business' API specific to that page. But we did not want to repeat all the merging logic on the server during launch. To alleviate the problem, I created a dependency graph/DAG for all the 12 APIs and fired HTTP requests concurrently at each level instead of using 12 promises which increased performance significantly. Does GraphQL support such use-cases?

leebyron 11y ago
GraphQL is designed for exactly this use case

WimLeers 11y ago

This does not explain how the client-side cache is kept up-to-date. Cache invalidation matters. You want instantaneous updates on the client if the data has been updated on the server. E.g. What if the like count has been updated? Curious what solutions GraphQL offers for this. If it doesn't solve this itself, then what do GraphQL apps do today to solve this?

ollysb 11y ago
Facebook does have an internal solution for push updates, I believe they use long http requests. There were some talk of relay adding support for updates via websockets, anyone have any information?
- WimLeers 11y ago
  Interesting; I'd love to read _what_ exactly they send in those long HTTP requests. I'd think something along the lines of Surrogate Keys/Cache Tags would make sense: - https://www.drupal.org/developing/api/8/cache/tags https://www.drupal.org/developing/api/8/cache/tags - http://info.varnish-software.com/blog/advanced-cache-invalidation-strategies http://info.varnish-software.com/blog/advanced-cache-invalid... (ugh, they broke their site, cached at https://pinboard.in/cached/a31c4630dd2d/ https://pinboard.in/cached/a31c4630dd2d/) - https://www.fastly.com/blog/surrogate-keys-part-1 https://www.fastly.com/blog/surrogate-keys-part-1 - https://blog.cloudflare.com/introducing-a-powerful-way-to-purge-cache-on-cloudflare-purge-by-cache-tag/ https://blog.cloudflare.com/introducing-a-powerful-way-to-pu...
  - sanderjd 11y ago
    Woah, thanks for those links. All very useful.
estefan 11y ago
There's been some mention of supporting subscriptions, but I haven't heard anything about implementation. I think it's on their roadmap.

gldalmaso 11y ago

Details about the backend are often vague or missing in every article that covers GraphQL that I've read so far. Where are guidelines to implement it? How do we make our existing business code integrate with it? How do we make sure a client cannot access data from another client? Does it work well or at all with relational databases? Is the backend a second-class citizen in this approach?

estefan 11y ago
There are several implementations. There's a reference in javascript based on express, sangria for scala, and I read on a blog post about people working on a ruby server. See: http://facebook.github.io/react/blog/2015/09/14/community-roundup-27.html http://facebook.github.io/react/blog/2015/09/14/community-ro... You basically define the schema, and for each method you want to support you implement pulling the data from your datastore. Authentication is up to you - stick a bearer header on your requests and implement checks in your server and you have secure backends, etc.
verbin217 11y ago
https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js Just implement resolve.
- xtrumanx 11y ago
  If you have two fields in a query, does that mean two resolve functions? If I using a SQL database and the two fields were stored on two columns on the same table, wouldn't that cause 2 SQL queries to be run?
  - verbin217 11y ago
    Yes. But only one http request. If they're both the same query but access a different field you might be able to cache it.
  - devit 11y ago
    Sangria in Scala has a mechanism called "Deferred" that lets you specify that it should ask you to resolve objects of a certain type all at once at the end, and you would do a single SQL query per object type there. If the JavaScript implementation doesn't have something like this, perhaps it can be hacked on top.

aikah 11y ago

Too invasive. GraphQL actually needs to be implemented on the server, which is a no go for me. The client should not dictate what the server api should look like. I understand it works for Facebook and it's fine, however this thing is so hyped right now developers are jumping into this and promoting this without actually talking about the drawbacks of this tech. And POST requests everywhere? excuse me but it throws away any "natural" http caching. To me it is another example of something that may benefit a project that has 500 million daily users , that is useless for 99% of projects out there, yet is advertised as a silver bullet that will make a poorly optimized app magically scale.

hippich 11y ago
I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint
- fernandotakai 11y ago
  the only problem is that, right now, there's no good lib that you can put on top of your existing infrastructure (for example, django's orm) that can translate graphql -> your-thing. i've been trying to write something like that, but it's kind of awkward, specially because the whole relay stack is not 100% feature stable.
  - hippich 11y ago
    this is official reference lib - https://github.com/graphql/graphql-js https://github.com/graphql/graphql-js you need to implement resolve method to map properties to your backend(s) yes, it is not drop in, but using any node.js http request library should do the trick. also, both can co-exist if you have application which already uses existing rest api layer.
- aikah 11y ago
  > I believe graphql can be added on top of your backend, even more - it can layer on top of multiple microservices backends to provide single api endpoint It is exactly what I'm saying. It's yet another layer on the server, it doesn't solve caching issues, and it will certainly not make your average app faster, especially when http2 support is here. GraphQL is an ORM for rest apis. I thought rest apis were supposed to be universal, why need another layer on top of it? How many ORMs do developers need ? how much more complex does it have to get? The goal of REST is first and foremost readability and simplicity. The purpose of fat clients are to push complexity on the client. With graphQL simplicity is gone since everything is POST thus no http caching, and the server now gets another layer of complexity instead of being client agnostic. Again, it might make sense at Facebook scale, but many articles promoting GraphQL are not talking about the fact that, it might not make sense for the majority of applications out there, even worse, it actually might make apps slower because of that extra layer.

deleted 11y ago

[deleted]

xtrumanx 11y ago

I'm a big fan of React but it took me a year after its introduction for me to get it and like it. What particularly did the trick for me was one of Pete Hunt's talks he gave a year after release acknowledging the confusion and explaining the reasoning for React rather than just the technology itself. I feel like GraphQL can be something great and the pain points they identify with typical APIs are stuff I've felt but GraphQL just feels incomplete to me. I feel they're focusing too much on what GraphQL looks like on the client-side and not enough what it looks like on the server-side. The biggest question I have is what's going to process the GraphQL query on the server to fetch the data from the actual datastore? What does that look like when working with typical datastore such as a SQL-based database? The closest thing I've seen that answered that question was this blog post[0] which doesn't look very appealing if that's what the server-side implementation is going to look like. The blog post's implementation looks like a more complicated version of my own APIs which are usually a series of custom endpoints based on my client's needs. I don't see the big deal right now. Maybe next year... [0] https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2 https://medium.com/@clayallsopp/your-first-graphql-server-3c...

estefan 11y ago
Check this out if you understand scala: https://github.com/sangria-graphql/sangria-akka-http-example https://github.com/sangria-graphql/sangria-akka-http-example Pulling data from a datastore is up to you. You can use whatever library you like to pull data in. All you have to do is make your `resolve` methods just return the data. The GraphQL schema definition is basically an adapter (as in adapter pattern) on top of your datastore(s).
insin 11y ago
I found this example in the dataloader README useful, as it deals with loading from a SQL-based database, with relationships, which is similar to the first project I'm planning on trying it with: https://github.com/facebook/dataloader#using-with-graphql https://github.com/facebook/dataloader#using-with-graphql
dustingetz 11y ago
GraphQL means UI components can stand on their own - they work without custom endpoints. And it's faster. You do need to write an adapter between GraphQL and your datastore, which is probably hard today, and probably easier next year, but you only need to pay that cost once.

MehdiHK 11y ago

I'm writing a series on learning GraphQL here, if anybody is interested: https://github.com/mugli/learning-graphql https://github.com/mugli/learning-graphql

owyn 11y ago

All the examples I've seen so far have a "hardcoded" schema expressed in code. Besides code generation, is there some way to express a schema in another format? Is anyone working on a way to define dynamic schemas? For example, a user defined schema rather than a developer defined schema. What I'd really like to see is a tool/library/framework to create a graphQL schema, store it in a database along with the data, and efficiently query the whole assembly. I'm thinking of something like Semantic Mediawiki that isn't terribad. :)