As a GraphQL application grows, placing everything in one schema file and one resolver file becomes difficult to maintain.

A modular structure can organize GraphQL capabilities by domain:

src/
  modules/
    users/
      user.schema.js
      user.resolvers.js
      user.service.js
      user.repository.js
    products/
      product.schema.js
      product.resolvers.js
      product.service.js
      product.repository.js
  graphql/
    schema.js
    context.js
  infrastructure/
    database.js
    cache.js
  server.js

The exact naming convention is less important than the ownership boundaries.

A users module can own user-related schema definitions, resolvers, services, and repositories. A products module can do the same for products.

The root GraphQL schema can then compose these domain definitions.

This modular approach becomes increasingly valuable when the application has multiple teams, because ownership and change boundaries become clearer.

However, modularity should not mean creating hundreds of tiny files without meaningful boundaries. A module should represent a cohesive domain or capability rather than an arbitrary number of functions.