
Thinking in GraphQL - bholdr
https://facebook.github.io/relay/docs/thinking-in-graphql.html
======
xtrumanx
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-3c...](https://medium.com/@clayallsopp/your-first-graphql-
server-3c766ab4f0a2)

~~~
insin
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)

------
gldalmaso
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?

~~~
verbin217
[https://github.com/graphql/graphql-js](https://github.com/graphql/graphql-js)

Just implement resolve.

~~~
xtrumanx
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?

~~~
leebyron
Only if each field required loading a new row, and even then batching can be
used to turn this back into one query.

eg: { firstName, lastName } doesn't need to load new rows but { mother { name
}, father { name } } does need to load new rows.

DataLoader
([https://github.com/facebook/dataloader](https://github.com/facebook/dataloader))
is a small utility which makes batching and caching database requests straight
forward.

------
WimLeers
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
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
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-
invalid...](http://info.varnish-software.com/blog/advanced-cache-invalidation-
strategies) (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-
pu...](https://blog.cloudflare.com/introducing-a-powerful-way-to-purge-cache-
on-cloudflare-purge-by-cache-tag/)

~~~
sanderjd
Woah, thanks for those links. All very useful.

------
pramodliv1
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
GraphQL is designed for exactly this use case

------
owyn
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. :)

------
MehdiHK
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)

------
aikah
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
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

~~~
aikah
> 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.

~~~
j_s
_GraphQL is an ORM for REST APIs._

If accurate, this might be the key take-away from this discussion.

~~~
estefan
It's not REST

~~~
j_s
I think the point was that GraphQL can slice & dice REST interfaces like an
ORM, not that GraphQL _is_ REST. I believe this is a part of the story -
GraphQL can sit in front of any datasource, not just REST-based ones.

