You can do whatever you want in the resolve function, but it’s a trade-off between flexibility and efficiency compared to plain old queries.

Let’s say you want the “friends of friends” of a person:

You would first retrieve the person from the database (e.g. with something like `persons.document(personId)`) in the resolve function of the person type.

Then you need to find the person’s friends, so you perform a second query that returns a cursor of the documents for each friend.

Then you want each friend’s friends. This is where it gets ugly. Let’s say the original person has six friends. This means you now have to perform the same query as in the previous step six times. If the person had twenty friends, you’d be performing it twenty times now.

With a plain database query (e.g. a static query for the same data written in AQL) you’d only perform a single query and get the entire result set at once.

In ArangoDB/Foxx this isn’t a huge problem because making a query only has the overhead of switching between (slow) JavaScript and (fast) native logic each time. With VelocyPack in ArangoDB 3.0 this will see even more performance improvements and less overhead.

But most examples and tutorials out there don’t use ArangoDB and Foxx. Instead they’re using an application server (typically Node) in front of the database (e.g. MongoDB). When GraphQL is executed outside the database this means that for each query I just described you also add the full network overhead of a roundtrip to the database: send the query over the wire, parse the query in the DB, serialize the result, send the serialized result back to the server and parse it to JavaScript.

In theory it’s possible to parse the incoming GraphQL query in the resolve function to precisely determine what data needs to be loaded to fully resolve the entire query but that means you need to write code that translates any valid GraphQL query to whatever query language your database understands. But depending on what your schema looks like, this can be extremely difficult and brittle: you’re again stuck either closely tying your internal data representation with the API schema or having to spend a lot of time tweaking backend code whenever you want to adjust your API — exactly what GraphQL otherwise allows you to avoid having to worry about.

`For example, in order to retrieve the friends of a person, the schema has to first retrieve the person and then retrieve the person’s friends using a second query.` (in The Bad section)

What does ‘retrieve’ mean in this sentence? As I understand it, it’s possible to perform whatever you want within the `resolve` function, including a complex traversal to get all required data (friends) at once. How is the GraphQL layer interfering with the database interface itself?

The schema.json Relay wants is just the output of this:

const util = require(‘graphql/utilities’);
const schemaDotJson = util.printSchema(graphql(Schema, util.introspectionQuery));

graphql-sync doesn’t currently have the utilities sub-module but you should be able to just install graphql-js alongside it and use the utilities from there (and the graphql function from graphql-sync).

graphql-sync is fully compatible with graphql-js, it just provides a copy of the outer most layer of the main API that removes the promise logic.

In other words, I feel an application layer is still needed between the GraphQL API and the database.

Scott

Yes. By resolving the GraphQL schema inside Foxx you can avoid the network overhead. It’s still not as efficient as using optimized AQL queries but it puts ArangoDB at a unique advantage compared to other databases that can’t resolve GraphQL internally.