type graphql
2.0.0-rc.2
使用类和装饰器创建GraphQL模式和用打字的解析器！
https://typegraphql.com
TypeGraphQL使开发GraphQl API成为一个愉快的过程，即仅使用类和一些装饰器魔术来定义模式。
因此，要创建诸如对象类型或输入类型之类的类型，我们使用一种DTO类。例如，要声明Recipe类型，我们简单地创建一个类并用装饰器注释：
@ ObjectType ( )
class Recipe {
@ Field ( type => ID )
id : string ;
@ Field ( )
title : string ;
@ Field ( type => [ Rate ] )
ratings : Rate [ ] ;
@ Field ( { nullable : true } )
averageRating ?: number ;
}我们在SDL中获得了架构的相应部分：
type Recipe {
id : ID !
title : String !
ratings : [ Rate ! ] !
averageRating : Float
}然后，我们可以创建查询，突变和现场解析器。为此，我们使用类似控制器的类，这些类别按照惯例称为“解析器”。我们还可以使用依赖注射和验证后卫等出色功能：
@ 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 ;
}
}以这种简单的方式，我们在SDL中获得了架构的这一部分：
type Query {
recipes : [ Recipe ! ] !
}
type Mutation {
removeRecipe ( id : String ! ): Boolean !
}我们都知道GraphQl很棒，并且解决了REST API的许多问题，例如过度提取和不足。但是，在带有打字稿的Node.js中开发GraphQl API有时会有些痛苦。为什么？让我们看一下通常必须采取的步骤。
首先，我们使用SDL在schema.graphql中创建所有GraphQl类型。然后，我们使用代表DB实体的ORM类创建数据模型。然后，我们开始为我们的查询，突变和字段编写解析器，但这迫使我们首先为所有参数，输入甚至对象类型创建TS接口。
只有这样，我们才能使用怪异的通用签名和手动执行常见任务，例如验证，授权和加载依赖项来实现解析器：
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 } ) ;
} ;最大的问题是我们的代码库中的冗余，这使得很难保持同步。要向我们的实体添加一个新字段，我们必须跳过所有文件 - 修改实体类，架构以及接口。输入或参数也是如此。很容易忘记更新一件或用一种类型犯错。另外，如果我们已经在字段名称中撰写了错别字怎么办？重命名功能（F2）无法正常工作。
诸如GraphQL代码生成器或GraphQlgen之类的工具仅求解第一部分 - 它们为我们的GraphQl架构生成相应的接口（和解析器骨架），但它们没有修复模式<->型号<->型号的型号和开发人员的经验（F2重命名的经验（F2重命名不起作用），您必须记住，您必须记住codegen在后台上的code gent of Codegen Watch the Backgrouns等，以及常见的效力，授权，授权，等等，等等，等等，等等。
TypeGraphQL根据几年在打字稿中开发GraphQL API的经验来解决这些问题。主要的想法是只能通过使用课程定义模式和一些装饰人员的帮助来拥有一个真理的来源。依赖注入，验证和AUTH守卫等其他功能通常会帮助我们处理自己的常见任务。
网站上可用文档，安装指南和API及其所有功能的详细说明。
可以在入门文档时找到一个完整的入门指南（教程）。
如果您喜欢视频教程，则可以在YouTube上观看Ben Awad的TypeGraphQL视频系列。
您还可以在此存储库中查看示例文件夹以获取更多用法示例：简单字段解析器，DI容器支持，TypeOmm集成，自动验证等。
测试文件夹还可能会为您提供一些有关如何完成各种工作的提示。
要报告安全漏洞，请使用Tidelift安全联系人。 Tidelift将协调修复和披露。
当前发布的版本是稳定的1.0.0版本。它经过良好的测试（97％的覆盖范围，约500例测试用例），并且已经实施了大多数计划的功能。许多公司和独立开发人员都成功地将其用于生产。
但是，还计划了更多功能，例如Better Typeorm，Prisma和DataLoader集成，定制装饰器和元数据注释支持 - 完整的想法列表可在GitHub Repo上获得。您还可以跟踪开发委员会在项目委员会上的进步。
如果您有任何有趣的功能请求，请随时在Github上打开问题，以便我们讨论！
TypeGraphQL是MIT许可的开源项目。该框架是大量工作的结果 - 不眠之夜，繁忙的夜晚和周末。
它没有一家大型公司坐在它的背后 - 只有在社区的支持下，它的持续发展才有可能。
请要求您的公司通过成为金牌赞助商并从我们的核心贡献者那里获得高级技术支持来支持这个开源项目。
