type graphql下載 - type graphql源代碼下載

使用類和裝飾器創建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守衛等其他功能通常會幫助我們處理自己的常見任務。