Translate GraphQL qureries to SQL

[benbro]

PostGraphile use look-ahead and Hasura translate GraphQL queries to SQL instead of using resolvers and batch loading.
Are there plans to go in this direction?
Being able to do it in erlang with authorization, middlewares and rate limiting might be very useful.

[Jesper Louis Andersen]

First, we don't think blind translation from GraphQL to SQL is a good approach. We've found that such a solution has a lot of limitations. To wit:

• Flow from Client to Server often requires you to tweak input data
• Flow from Server to Client likewise requires a lot of changes
• GraphQL schemas often glues a lot of backend services together.
• It is alluring to automatically generate SQL from a GraphQL query, but as systems grow, this quickly becomes a serious limitation. You cannot avoid having a programmer in between who can think for the system. I.e., it works for your weekend-reddit-clone, but it doesn't scale.

As an example, Shopguns schema straddles Graph Databases, SQL, Message Queues, and Search Engines.

So there are no immediate plans. However:

• If you write resolvers building up a response, you can view that as an input to a "next phase" in your engine. This "next phase" could be SQL formulation, which would allow you to fire off a SQL query. I.e., you are not producing JSON for the client to consume, but an Erlang term for the SQL execution engine to consume.
• We do have a farsight plan, where the internal execution engine is a small (lambda calculus based) language, and GraphQL is a compiler to this intermediate representation. It would definitely be possible to consider multiple backends for the IR. One for our current solution, and one for compiling into SQL.
• The lookAhead feature of PostGraphile is interesting, and we might adopt that in the future, if we need it in our system, or someones goes ahead and sponsors that work. In our system, the Ctx would contain functionality to query into the deeper structure in order to obtain hints about the future execution. This could guide, e.g., eager loading of data for the current node, rather than relying on a reactive approach as is the Data Loader.

[benbro]

Thanks