DEV Community

Cover image for Manage Circular Imports Hell in GraphQL-Modules
TheGuildBot for The Guild

Posted on • Updated on • Originally published at the-guild.dev

Manage Circular Imports Hell in GraphQL-Modules

This article was published on Monday, March 18, 2019 by Arda Tanrikulu @ The Guild Blog

Designing and building modular GraphQL API may not look straight-forward the first time you start.
It is hard to keep a perfect modularity with standalone and encapsulated modules.It is really easy to appeal to the circular imports, but that's exactly what you shouldn't do in any
case. You might say while reading this; I DON'T HAVE ANY WAY OF NOT CREATING CIRCULAR IMPORTS!In a previous versions of GraphQL-Modules, we used to allow users to have circular imports in their
GraphQL-Modules applications. However, it created a lot of extra logic which slows down the initial
schema generation speed, because we always need to check if there is circular imports between
modules.Then, if GraphQL-Modules found some, it would merge all the members of this circular import
into a one LARGE MODULE which was breaking almost every principle of encapsulation and
modularity
we mentioned in previous blog-posts of our GraphQL-Modules series.Finally, we decided to remove this support; then force people to have strict modularity
in their projects./blog/modular-encapsulation-graphql-modulesForcing people out of a way of developing is always hard, and we've got
questions from you about how to solve some
specific issues — so in this blog post and new doc section we will help you understand why this was
a bad practice and how to migrate from it with different use cases.## The ProblemLet's assume we have 3 different entities in our database;* User

  • Post
  • CommentThen, if we create three different modules for these three entities; graphql type User { id: ID name: String username: String email: String ## Some other fields posts: [Post] comments: [Comment] }
type Post {
  id: ID
  title: String
  content: String
  user: User
  comments: [Comment]
}
Enter fullscreen mode Exit fullscreen mode
type Comment {
  id: ID
  content: String
  user: User
  post: Post
}
Enter fullscreen mode Exit fullscreen mode


As you can see above, every module imports other modules; and this creates a circular dependency.You might ask if this is the only way to implement modules for these entities; because it looks like
there is no point to have different modules for those schemas. Having circular dependency is the
same situtation with having a single large module.## How to SolveLet's see what we have in terms of relationship; - User doesn't depend on Post and Comment -
Post doesn't depend on Comment.* Comment depends on User and Post, because it has userId and postId fields - Post also
depends on User because it has userId fieldSo let's create modules in that way,

type User {
  id: ID
  name: String
  username: String
  email: String
  ## Some other fields
}
Enter fullscreen mode Exit fullscreen mode
type Post {
  id: ID
  title: String
  content: String
  user: User
}
extend type User {
  posts: [Post]
}
Enter fullscreen mode Exit fullscreen mode
type Comment {
  id: ID
  content: String
  user: User
  post: Post
}
extend type Post {
  comments: [Comment]
}
extend type User {
  comments: [Comment]
}
Enter fullscreen mode Exit fullscreen mode

Using this approach, you will have standalone modules; otherwise will create a big module which
contains all of them like we used to handle circular deps in this way (merging all circular
imports
).Also extend says that it needs a main definition from imported modules which makes the connection
more readable in terms of entity relations.**## All Posts about GraphQL Modules GraphQL Modules — Feature based GraphQL Modules at scale

Top comments (0)