Building GraphQL APIs in TypeScript: Nexus vs Prisma vs TypeGraphQL

When building modern full-stack applications with GraphQL and TypeScript, developers often reach for libraries that bridge the gap between type safety, database access, and schema definition. nexus, prisma, and type-graphql each play distinct roles in this ecosystem — but they are frequently confused because they overlap in purpose or are used together. Let’s clarify what each does, how they differ technically, and where they fit in a real-world stack.

🧩 Core Responsibilities: What Each Package Actually Does

nexus is a GraphQL schema construction library. It helps you define your GraphQL types, queries, and mutations in code using a strongly typed, declarative API. It does not handle database operations or object-relational mapping.

// nexus: Define GraphQL schema in code
import { makeSchema, objectType, queryType } from 'nexus';

const User = objectType({
  name: 'User',
  definition(t) {
    t.string('id');
    t.string('name');
  }
});

const Query = queryType({
  definition(t) {
    t.field('user', {
      type: User,
      resolve: () => ({ id: '1', name: 'Alice' })
    });
  }
});

export const schema = makeSchema({ types: [User, Query] });

prisma is an ORM (Object-Relational Mapper) with a powerful schema-driven workflow. It generates a type-safe client from a declarative data model, enabling direct database access without writing raw SQL. While Prisma can be used with REST or GraphQL, it does not define GraphQL schemas by itself.

// prisma/schema.prisma
model User {
  id   String @id @default(cuid())
  name String
}

// prisma: Use generated client to fetch data
import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();

const user = await prisma.user.findUnique({ where: { id: '1' } });
// Fully typed result based on schema

type-graphql is a GraphQL schema generator that uses TypeScript decorators to automatically produce a GraphQL schema from class definitions. Like nexus, it focuses on schema creation — not database interaction.

// type-graphql: Define schema via decorators
import { ObjectType, Field, Query, Resolver } from 'type-graphql';

@ObjectType()
class User {
  @Field()
  id: string;

  @Field()
  name: string;
}

@Resolver()
class UserResolver {
  @Query(() => User)
  user() {
    return { id: '1', name: 'Alice' };
  }
}

⚠️ Important: As of 2023, the nexus package is deprecated. The official Nexus documentation now recommends migrating to alternatives like type-graphql or using Prisma with standalone GraphQL libraries. New projects should avoid nexus.

🔌 Integration Patterns: How These Tools Work Together

In practice, these tools are often combined, not chosen in isolation:

• Prisma + TypeGraphQL: A very common pairing. Prisma handles database access; TypeGraphQL defines the GraphQL layer.
• Prisma + Nexus: Was popular before Nexus was deprecated.
• TypeGraphQL alone: Possible if you manage data fetching manually (e.g., with raw SQL or another ORM).

Example: Prisma + TypeGraphQL in Action

// 1. Prisma model (schema.prisma)
model Post {
  id    String @id
  title String
  author User   @relation(fields: [authorId], references: [id])
  authorId String
}

// 2. TypeGraphQL resolver using Prisma client
import { Resolver, Query, Arg } from 'type-graphql';
import { Post } from './entities/Post';
import { prisma } from './prisma';

@Resolver()
export class PostResolver {
  @Query(() => [Post])
  async posts() {
    return prisma.post.findMany();
  }

  @Query(() => Post)
  async post(@Arg('id') id: string) {
    return prisma.post.findUnique({ where: { id } });
  }
}

This combo gives you end-to-end type safety: from database → Prisma client → resolver → GraphQL response.

🛠️ Schema Definition Style: Code-First vs Decorator-Driven

nexus uses a functional, builder-style API. You define types by calling functions like objectType() and queryType(). This approach is explicit and composable but requires more boilerplate.

// nexus style (deprecated)
const Post = objectType({
  name: 'Post',
  definition(t) {
    t.string('id');
    t.string('title');
    t.field('author', { type: User });
  }
});

type-graphql uses decorators on classes, which feels more natural if you’re already using classes and OOP patterns in TypeScript. The schema is inferred from metadata.

// type-graphql style
@ObjectType()
class Post {
  @Field()
  id: string;

  @Field()
  title: string;

  @Field(() => User)
  author: User;
}

Developers who prefer functional composition may have favored nexus, while those comfortable with decorators lean toward type-graphql. However, since nexus is deprecated, type-graphql (or newer alternatives like typegraphql-prisma) is the pragmatic choice for decorator-based workflows.

🔄 Data Fetching: Who Handles the Database?

None of these packages — except Prisma — talk to a database directly.

• Prisma: Provides a generated client (PrismaClient) that maps 1:1 to your database schema. Queries are type-safe and auto-completed in IDEs.
• Nexus & TypeGraphQL: Only define the interface (GraphQL schema). You must write resolvers that fetch data from somewhere — often Prisma, but could also be REST APIs, MongoDB drivers, etc.

If you try to use type-graphql without a data layer, you’ll end up mocking data or writing low-level database calls:

// Without Prisma: manual data fetching
@Query(() => User)
user() {
  // You'd need to write this yourself
  return db.query('SELECT * FROM users WHERE id = ?', ['1']);
}

That’s why Prisma is complementary, not competitive, with the other two.

🧪 Type Safety and Developer Experience

All three aim for strong TypeScript integration, but achieve it differently:

• Prisma: Generates TypeScript types from your schema.prisma file. Your database model becomes your source of truth.
• TypeGraphQL: Uses reflection and decorators to infer GraphQL types from TypeScript classes. Requires reflect-metadata and proper tsconfig.json settings.
• Nexus: Used its own type inference system (now unmaintained).

With Prisma + TypeGraphQL, you get double type safety:

1. Prisma ensures your database queries match your schema.
2. TypeGraphQL ensures your GraphQL resolvers match your exposed API.

But you must keep both layers in sync manually — unless you use a tool like typegraphql-prisma, which auto-generates TypeGraphQL classes from your Prisma schema.

📦 Real-World Architecture Recommendations

For New Projects

• Do not use nexus — it’s deprecated.
• If you want a code-first GraphQL API with an ORM, use Prisma + TypeGraphQL.
• If you prefer minimal dependencies, consider using Prisma with Apollo Server directly (defining schema via SDL strings), though you lose some type safety.

Example Minimal Stack (Prisma + Apollo Server)

// Define schema as string
const typeDefs = gql`
  type User {
    id: ID!
    name: String!
  }
  type Query {
    user(id: ID!): User
  }
`;

// Resolver uses Prisma
const resolvers = {
  Query: {
    user: (_parent, { id }, _context) => {
      return prisma.user.findUnique({ where: { id } });
    }
  }
};

This avoids type-graphql entirely but requires manual schema/resolver alignment.

🆚 Summary: Roles and Recommendations

💡 Final Guidance

• Need an ORM? → Use Prisma. It’s the only true database toolkit here.
• Building a GraphQL API with decorators? → Use TypeGraphQL (and pair it with Prisma for data).
• Considering Nexus? → Don’t. It’s no longer maintained. Migrate existing projects to alternatives.

Remember: Prisma solves data persistence; TypeGraphQL solves API definition. They answer different questions — and work best when used together.