Why is True Modular Encapsulation So Important in Large-Scale GraphQL Projects? — GraphQL Modules is your savior!

Encapsulation matters in large-scale projects

TL;DR: If you are writing a large-scale project, it’s necessary to understand the relations between your pieces of code, and how they effect each other. Otherwise, it might be difficult to deal with changes later.

While developing a large-scale project, removing, changing and modifying parts of the project can become a very time consuming and risky task, because understanding the full side-effects of those changes is very hard.

In GraphQL-Modules, you can declare your modules in a feature-based structure, with clear enforced boundaries and avoid unexpected side-effects during development.

Each module can declare it’s own scope of the complete schema:

Every module has its own schema, context and DI container. Here you can see AuthModule is appended to UserModule. But, other modules don’t import AuthModule. So, they cannot access directly AuthModule DI container or context.

Each module has its own schema, context, typeDefs, resolvers, and business-logic and each module is encapsulated, which limits the module’s access to only its own parts of the schema.

So, what’s the real benefit of this?

Let’s assume you have an authentication module;

After a while, you decided to use AccountsJS in your GraphQL project which has completely different implementation than the existing one.

This can be a risky change, because you’re afraid of breaking a lot of things and you can’t be sure about the all the places in your code that uses values affected by the authentication module, for example the global context.

With GraphQL-Modules’s approach of encapsulation, even the context is completely encapsulated, so every module that uses your existing AuthenticationModule’s context in defined on theimports of the dependent modules, and its interface is already extended by AuthenticationModule’s context if you’re using TypeScript. When it is removed, you will notice that change on compile-time immediately.

Let’s take a look at some code, to show how GraphQL Modules makes you create those dependencies explicitly.

AppModule is our top Application Module;

Example Application Module that imports AuthenticationModule

And there is another module that tries to use AuthenticationModule’s context, but it doesn’t import AuthenticationModule. In this case, it is not possible to get anything from AuthenticationModule in the resolvers, because it is not imported. The following module doesn’t know anything about AuthenticationModule.

Example Module that tries to use

To fix this, we need to import AuthenticationModule into that ‘important’ module to make it able to access AuthenticationModule’s context like below;

So, these examples above show us that the encapsulation can be very important in the long term of our project development.

We think modular approach is not just merging schemas and concatenate context factory functions to each other.

Having a tool that knows how to encapsulate modules and force this policy, makes it much easier to write modular schema, and later, even reuse existing modules and share them across multiple projects.

All posts about GraphQL Modules

1. GraphQL Modules — Feature based GraphQL Modules at scale
2. Why is True Modular Encapsulation So Important in Large-Scale GraphQL Projects?
3. Why did we implement our own Dependency Injection library for GraphQL-Modules?
4. Scoped Providers in GraphQL-Modules Dependency Injection
5. Writing a GraphQL TypeScript project w/ GraphQL-Modules and GraphQL-Code-Generator
6. Authentication and Authorization in GraphQL (and how GraphQL-Modules can help)
7. Authentication with AccountsJS & GraphQL Modules
8. Manage Circular Imports Hell with GraphQL-Modules

Follow us on GitHub and Medium, we are planning to release many more posts in the next couple of weeks about what we’ve learned using GraphQL in recent years.