[seanlaff]

In the reference implementations of GQL, that “one query” from the client balloons out in to possible hundreds of queries out the back side of GQL.

Things like dataloader exist but the behavior of your schema gets harder and harder to reason about when different caching mechanisms get thrown on top.

I think everyone agrees that the client facing api for GQL is fantastic... maybe that means graphdbs are the next wave :P

[tracker1]

For distributed data stores, with collectives of data across different databases/clusters it starts to make more sense.

If you're using a column store structure for most data, you're mainly doing individual lookups based on a single key, graph data in another key/keys, and related keys looked up separately. Each optimized for the single record(s).

Especially since distributed/collectively this data will be accessed faster than a single rdbms would be able to manage.

That said, if your application can/does use a single sql datastore, and you don't need that much scale, the effort to setup/configure GQL may not be worth it in a given instance.

[WiseWeasel]

To me, on the back-end, GraphQL means replacing controllers with query (GET) and mutation (POST/PUT/DELETE) resolvers, with very similar concerns, routing takes place in the GQL schema, and everything else stays the same.