N+1 SQL queries about graphql-erlang HOT 1 CLOSED

You have a number of options in the current state of the system:

Option 1: when resolving books(genre: ..) you load every row and every possible column on that row. When resolving the Book itself, you grab inside the fully loaded object. This is actually not as insane as it sounds: you'll need the full row anyway for a cache.

Option 2: resolve the IDs of books on the books(genre: ...) field, then issue a fetch on the fields which are not satisfiable in a cache.

Option 3: Don't return a JSON structure. Return data which can be used to perform an SQL query and then perform it later on. The idea is that GraphQL is but the first stage of a resolution which dynamically forms the SQL query needed. Then you send the query through something such as sqerl to form the actual query and execute it. Note that this is going to be destroying your database as you expose the world to queries.

Once we have proper concurrent field resolution in, we can start using a data loader pattern for this, which is probably going to be better from a cache-perspective, but that is in the future.

The TL;DR is: Not a GraphQL problem. The current lack of concurrent execution in the engine may hamper a bit, though.

from graphql-erlang.