---

Performance-Optimized Fork by Scope3

Context: This is a high-performance fork maintained by Scope3 with significant optimization improvements. Our changes have been submitted as PR #1779 to the original repository but remain unmerged after 6+ months.

Performance Improvements

What’s Different in the Scope3 Fork?

This fork introduces a major refactor of the TypeGraphQL metadata build process, focused on dramatically improving performance for large schemas. It works very well! Scope3 has been running this fork in production for over 6 months, dropping our schema generation time from 4-5 minutes to under 10 seconds in our K8s deployments.

Problem:
Schema generation in the upstream project was exponentially slow for large schemas, taking 30+ seconds with 3k-15k metadata objects due to repeated O(n) array .filter() lookups.

Scope3 Solution:
We replaced all repeated array lookups with O(1) HashMap-based caching.

• Added cache initialization for all major metadata types (object types, fields, params, middlewares, directives, resolver classes, etc.).
• All metadata lookups now use these caches instead of array .filter() calls.
• Refactored resolver and field metadata construction to leverage these caches.

Technical Details:

• Introduced Map caches for object types, fields, params, middlewares, directives, and resolver classes.
• Added an initCache() method to populate these caches before schema building.
• All metadata construction logic now uses these caches for instant lookup.

Performance Impact:

• Schema generation time reduced from tens of seconds to milliseconds for large schemas.
• Example:
  • buildClassMetadata: 31.3s → 268ms (116x faster)
  • buildFieldResolverMetadata: 314ms → 39ms (8x faster)
  • buildResolversMetadata: 1.4s → 126ms (11x faster)

Compatibility:

• The fork remains 100% backward compatible with the original TypeGraphQL API.
• All original TypeGraphQL tests pass with these changes.
• Scope3 has been running this fork in production for over 6 months.
• All recent upstream changes are documentation-only (sponsor updates).

---

If you want more technical details or code samples, see the source or reach out to Scope3!

Installation

# Install with npm
npm install @scope3data/type-graphql

# Install with Yarn
yarn add @scope3data/type-graphql

# Install with PNPM
pnpm add @scope3data/type-graphql

What's Coming

• Prisma 6 support – Upgrading to the latest Prisma version
• GraphQL 16.11 – Latest GraphQL version with improved performance and features

Compatibility

100% backward compatible – drop-in replacement for the original type-graphql package.

---

TypeGraphQL

Create GraphQL schema and resolvers with TypeScript, using classes and decorators!

https://typegraphql.com

Introduction

TypeGraphQL makes developing GraphQL APIs an enjoyable process, i.e. by defining the schema using only classes and a bit of decorator magic.

So, to create types like object type or input type, we use a kind of DTO class. For example, to declare Recipe type we simply create a class and annotate it with decorators:

@ObjectType()
class Recipe {
  @Field(type => ID)
  id: string;

  @Field()
  title: string;

  @Field(type => [Rate])
  ratings: Rate[];

  @Field({ nullable: true })
  averageRating?: number;
}

And we get the corresponding part of the schema in SDL:

type Recipe {
  id: ID!
  title: String!
  ratings: [Rate!]!
  averageRating: Float
}

Then we can create queries, mutations and field resolvers. For this purpose, we use controller-like classes that are called "resolvers" by convention. We can also use awesome features like dependency injection and auth guards:

@Resolver(Recipe)
class RecipeResolver {
  // dependency injection
  constructor(private recipeService: RecipeService) {}

  @Query(returns => [Recipe])
  recipes() {
    return this.recipeService.findAll();
  }

  @Mutation()
  @Authorized(Roles.Admin) // auth guard
  removeRecipe(@Arg("id") id: string): boolean {
    return this.recipeService.removeById(id);
  }

  @FieldResolver()
  averageRating(@Root() recipe: Recipe) {
    return recipe.ratings.reduce((a, b) => a + b, 0) / recipe.ratings.length;
  }
}

And in this simple way, we get this part of the schema in SDL:

type Query {
  recipes: [Recipe!]!
}

type Mutation {
  removeRecipe(id: String!): Boolean!
}

Motivation

We all know that GraphQL is great and solves many problems we have with REST APIs, like Over-Fetching and Under-Fetching. But developing a GraphQL API in Node.js with TypeScript is sometimes a bit of a pain. Why? Let's take a look at the steps we usually have to take.

First, we create all the GraphQL types in schema.graphql using SDL. Then we create our data models using ORM classes, which represent our DB entities. Then we start to write resolvers for our queries, mutations and fields, but this forces us to first create TS interfaces for all arguments, inputs, and even object types.

Only then can we implement the resolvers using weird generic signatures and manually performing common tasks, like validation, authorization and loading dependencies:

export const getRecipesResolver: GraphQLFieldResolver<void, Context, GetRecipesArgs> = async (
  _,
  args,
  ctx,
) => {
  // common tasks repeatable for almost every resolver
  const repository = TypeORM.getRepository(Recipe);
  const auth = Container.get(AuthService);
  await joi.validate(getRecipesSchema, args);
  if (!auth.check(ctx.user)) {
    throw new NotAuthorizedError();
  }

  // our business logic, e.g.:
  return repository.find({ skip: args.offset, take: args.limit });
};

The biggest problem is redundancy in our codebase, which makes it difficult to keep things in sync. To add a new field to our entity, we have to jump through all the files - modify an entity class, the schema, as well as the interface. The same goes for inputs or arguments. It's easy to forget to update one piece or make a mistake with a single type. Also, what if we've made a typo in the field name? The rename feature (F2) won't work correctly.

Tools like GraphQL Code Generator or graphqlgen only solve the first part - they generate the corresponding interfaces (and resolvers skeletons) for our GraphQL schema but they don't fix the schema <--> models redundancy and developer experience (F2 rename won't work, you have to remember about the codegen watch task in the background, etc.), as well as common tasks like validation, authorization, etc.

TypeGraphQL comes to address these issues, based on experience from a few years of developing GraphQL APIs in TypeScript. The main idea is to have only one source of truth by defining the schema using classes and some help from decorators. Additional features like dependency injection, validation and auth guards help with common tasks that normally we would have to handle ourselves.

Documentation

The documentation, installation guide, and detailed description of the API and all of its features are available on the website.

Getting started

A full getting started guide with a simple walkthrough (tutorial) can be found at getting started docs.

Video tutorial

If you prefer video tutorials, you can watch Ben Awad's TypeGraphQL video series on YouTube.

Examples

You can also check the examples folder in this repository for more examples of usage: simple fields resolvers, DI Container support, TypeORM integration, automatic validation, etc.

The Tests folder might also give you some tips on how to get various things done.

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

The future

The currently released version is a stable 1.0.0 release. It is well-tested (97% coverage, ~500 test cases) and has most of the planned features already implemented. Plenty of companies and independent developers are using it in production with success.

However, there are also plans for a lot more features like better TypeORM, Prisma and DataLoader integration, custom decorators and metadata annotations support - the full list of ideas is available on the GitHub repo. You can also keep track of development's progress on the project board.

If you have any interesting feature requests, feel free to open an issue on GitHub so we can discuss that!

Support

TypeGraphQL is an MIT-licensed open-source project. This framework is a result of the tremendous amount of work - sleepless nights, busy evenings and weekends.

It doesn't have a large company that sits behind it - its ongoing development is possible only thanks to the support of the community.

Gold Sponsors 🏆

Please ask your company to support this open source project by becoming a gold sponsor and getting a premium technical support from our core contributors.

Silver Sponsors 🥈

Leofame

Bronze Sponsors 🥉

Live Graphic Systems	LifeX Aps	instinctools	WordHint	Strands Hint

NonGamstopBets	CasinoDeps	Non Stop Casino	Graming	BetWinner	Famety	BuzzVoice	SocialWick	C19

SidesMedia	Social Followers	IG Comment	Twicsy	Buzzoid	Social Mention	TikTok Expert	Tokmax	UseViral

Members 💪

GitHub Sponsors

Community

• Visit the Official Website
• Chat on Discord

Want to help?

Want to file a bug, contribute some code, or improve the documentation? Great! Please read our guidelines for CONTRIBUTING and then check out one of our help-wanted issues.