TypeGraphQL alternatives and similar modules
Based on the "Web Frameworks" category.
Alternatively, view TypeGraphQL alternatives based on common mentions on social networks and blogs.
-
Nest
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript ๐ -
Nuxt.js
DISCONTINUED. Nuxt is an intuitive and extendable way to create type-safe, performant and production-grade full-stack web apps and websites with Vue 3. [Moved to: https://github.com/nuxt/nuxt] -
AdonisJs Framework
AdonisJS is a TypeScript-first web framework for building web apps and API servers. It comes with support for testing, modern tooling, an ecosystem of official packages, and more. -
Quick Start
๐ A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. ๐ -
Encore
Open Source Development Platform for building robust type-safe distributed systems with declarative infrastructure -
Derby
MVC framework making it easy to write realtime, collaborative applications that run in both Node.js and browsers -
NestJS REST API boilerplate
NestJS boilerplate. Auth, TypeORM, Mongoose, Postgres, MongoDB, Mailing, I18N, Docker. -
ActionHero
Actionhero is a realtime multi-transport nodejs API Server with integrated cluster capabilities and delayed tasks -
Lad
Node.js framework made by a former @expressjs TC and @koajs team member. Built for @forwardemail, @spamscanner, @breejs, @cabinjs, and @lassjs. -
Marble.js
Marble.js - functional reactive Node.js framework for building server-side applications, based on TypeScript and RxJS. -
lychee.js
DISCONTINUED. :seedling: Next-Gen AI-Assisted Isomorphic Application Engine for Embedded, Console, Mobile, Server and Desktop -
Hemera
๐ฌ Writing reliable & fault-tolerant microservices in Node.js https://hemerajs.github.io/hemera/ -
Catberry
Catberry is an isomorphic framework for building universal front-end apps using components, Flux architecture and progressive rendering. -
dawson-cli
DISCONTINUED. A serverless web framework for Node.js on AWS (CloudFormation, CloudFront, API Gateway, Lambda) -
AdonisJs Application
DISCONTINUED. This repo is the pre-configured project structure to be used for creating ambitious web servers using AdonisJs. -
QueryQL
Easily add filtering, sorting, and pagination to your Node.js REST API through your old friend: the query string! -
express-version-route
A Node.js express middleware that implements API versioning for route controllers -
FortJs
A feature-rich Node.js web framework designed for building powerful, scalable, and maintainable web applications. -
Prim+RPC
Easy-to-understand, type-safe, transport-agnostic RPC/IPC for JavaScript, supporting callbacks, batching, file handling, custom serialization, and more.
CodeRabbit: AI Code Reviews for Developers
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of TypeGraphQL or a related project?
README
TypeGraphQL
[](<(https://opencollective.com/typegraphql)>)
Create GraphQL schema and resolvers with TypeScript, using classes and decorators!
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 classes.
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 overfetching and underfetching. 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.gql
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 actually 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 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 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, detailed description of the API and all of its features is 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 how to get various things done.
The future
The currently released version is a stable 1.0.0 release. It is well tested (95% coverage, 428 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 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 - its ongoing development is possible only thanks to the support by the community.
Gold Sponsors ๐
ECAD Labs |
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 ๐ฅ
Lovd |
Bronze Sponsors ๐ฅ
Live Graphic Systems | LifeX Aps | SwissMentor | Flatirons Development | *instinctools | Rubyroidlabs | Intexsoft |
Members ๐ช
Backers โ
Want to help?
Want to file a bug, contribute some code, or improve documentation? Great! Please read our guidelines for contributing and then check out one of our help wanted issues.
*Note that all licence references and agreements mentioned in the TypeGraphQL README section above
are relevant to that project's source code only.