[NightMKoder]

Facebook’s Relay solves the throughput problem by effectively precompiling queries. Their production apps only make a subset of the requests of the full graphql language - and those are frozen at deploy/compile time. In some sense this makes their production graphql more like “auto-generated REST” from the server’s perspective.

That said, thinking of this in terms of client vs server devs isn’t useful - it’s not like anyone on the team want to see the servers burn. The beauty of graphql is it’s descriptiveness - you could create a query performance score and fail CI if your main page queries are hitting too high of a cost. A meet up in SF last year had some FB engineers discussing this - they do something along these lines before shipping their android/iOS apps.

[KirinDave]

> Facebook’s Relay solves the throughput problem by effectively precompiling queries. Their production apps only make a subset of the requests of the full graphql language

I am aware of this, and it seems ridiculous to me. It discards the value of having a graph query language. I'm open to being wrong about this assessment.

Why am I using a new query language if it's going to end up being exactly the same as the old rest query environment?

> That said, thinking of this in terms of client vs server devs isn’t useful

Considering it from a typical labor division standpoint or by technical dependency and requirements isn't useful? I disagree.

> The beauty of graphql is it’s descriptiveness

Which you have said the "performant" way to handle is to discard and turn into a formulaic series of bytes that is indistinguishable form a new term encoding on restful POST bodies.

> you could create a query performance score and fail CI if your main page queries are hitting too high of a cost.

This is exactly how everyone already tools RESTful endpoints. Whole industries are built around scoring endpoints this way.

Inevitably my concern about GraphQL being hard to implement server side is inevitably met with Facebook's outer and inner solution. The outer solution: Just pretend it's graphql, really it's postbodies and we won't let you write custom queries except for column filtering (which these solutions WILL fetch).

The inner solution, it has been intimated to me, is they have custom GQL libraries written in Haskell using Haxl that they don't share because the industry is too busy being afraid of it. Sadly, these don't appear to be open source (and even if they were, a lot of shops would not be equipped to use them).

[riffraff]

> Why am I using a new query language if it's going to end up being exactly the same as the old rest query environment?

the client controls the APIs without you touching them. It is required that the client syncs up with the server but you don't have to touch backend code to change the set of fields you want (this works for internal clients, not open APIs, clearly).

If you're thinking "but I can just allow the client to select fields in my JSONAPI compliant endpoint", yes, you can, and when you add includes for nested fields, and nested selections, you basically get 90% of graphql :)

[KirinDave]

> yes, you can, and when you add includes for nested fields, and nested selections, you basically get 90% of graphql :)

True, but until someone provides a great software kit for doing that work, I'm not going to allow arbitrary extensions.