Bidirectional Object Relationships

Drawing Both Arrows Between Posts and Authors

An author page lists their posts; each post shows its author. In SQL you join one way and issue a second query the other way. In a schema you declare both arrows and let one document walk them:

type Post {
  id: ID!
  title: String!
  author: User!
}

type User {
  id: ID!
  name: String!
  posts(limit: Int = 10, orderBy: Order = NEWEST): [Post!]!
}

query AuthorWithFootprint {
  user(id: "7") {
    name
    posts(limit: 5) {
      title
      author {   # back to the type we started from — legal, and occasionally useful
        name
      }
    }
  }
}

The schema is a directed graph. Bidirectionality simply means each type holds an edge to the other:

  Post -----author----> User
    ^                      |
    |------- posts---------|

Notice what the SDL does not contain: foreign keys. Post.author describes a relationship; whether it is satisfied by a join, a lookup, or a cached edge belongs to the resolver layer. That split is why the same schema can be served by a relational database, a document store, or a REST aggregate without changing a single client query.

Cycles at the type level do not imply cycles at execution time — execution follows the document, and documents are finite. The real costs live in how each edge is resolved, which the next two chapters take apart.

What the two-way declaration buys, compared with the same read elsewhere:

Because both edges sit next to each other in the SDL, a reviewer sees the whole relationship at once — and a client can walk from a post to its author and back to that author's other posts without the server ever issuing a second request.

Why Circular Types Validate and Circular Spreads Do Not

Schema validation runs once over the whole type graph, not type by type in declaration order. There is no "first type" to resolve, so Post.author: User alongside User.posts: [Post!]! is fully legal — the validator walks edges and checks field types, and revisiting a type means the graph is consistent, not broken.

Documents are held to a stricter rule, because a document must terminate. A fragment that reaches itself is rejected:

query Loop {
  user(id: "1") {
    name
    posts { author { ...AuthorLoop } }
  }
}

fragment AuthorLoop on User {
  name
  posts { author { ...AuthorLoop } }
}

Fragment "AuthorLoop" cannot be spread here as it would create a cycle.

The rule is called No Fragment Cycles. It is the only thing that stops an infinite query from being written; with it, depth can grow only by spelling each level out literally, which is exactly what a depth limit counts.

Practical consequences:

• Circular types are a modeling feature. Users follow users, categories nest categories, comments reply to comments, org units report to org units. Rejecting them means rejecting the domain.
• Every recursive edge needs a bound. A field like friends: [User!]! with no limit accepts a finite document that triggers unbounded work — paginate it or give it a default cap.
• Flag the right thing in review. "This type references itself" is a false positive; "this recursive list has no limiting argument" is the finding that matters.

See circular queries and cycle guards for the depth, cost, and resolver-side controls that bound what clients can write through a cycle.

Keeping Both Directions Symmetric and Terminating

Asymmetry is the drift bug of relational schemas. Post.author accepts nothing while User.posts(limit:) paginates, so clients discover two dialects for one edge and every consumer writes its own workaround.

Match arguments across the edge. Where one side filters, the other filters too:

type Post {
  author(includePostCount: Boolean = false): User!
}
type User {
  posts(limit: Int = 10, orderBy: Order = NEWEST): [Post!]!
}

Both resolvers terminate by construction — each reads an id from the parent and loads one bounded page:

const resolvers = {
  Post: {
    author: (post, _args, { loaders }) => loaders.user.load(post.authorId),
  },
  User: {
    // parent is the user; never reach back through Post.author from here
    posts: (user, { limit, orderBy }, { db }) =>
      db.post.findMany({ where: { authorId: user.id }, take: limit, orderBy }),
  },
};

The loop that actually bites is not in the schema but in resolver code that walks both edges eagerly: load a user, expand posts, load each post's author, expand their posts, and keep going. Bound any such traversal with a visited set and a depth counter — never with an unbounded loop over relations.

That last row is the production trap: if an author lookup is permitted through Post.author, the same person's data reached via User.posts must be authorized again. Access rules belong to each edge's resolver, not to one choke point — see role-based field access.

Interview question to expect: "Can a schema have circular references?" Answer yes at the type level, explain that validation runs over the whole graph, then add that fragment cycles are rejected and depth limits bound the rest — that sequence shows you understand where each rule applies.