type graphql
2.0.0-rc.2
¡Cree esquema GraphQL y resueltos con TypeScript, utilizando clases y decoradores!
https://typegraphql.com
TypeGraphql hace que el desarrollo de las API GraphQL sea un proceso agradable, es decir, definiendo el esquema usando solo clases y un poco de magia decoradora.
Entonces, para crear tipos como tipo de objeto o tipo de entrada, usamos un tipo de clase DTO. Por ejemplo, para declarar el tipo Recipe , simplemente creamos una clase y la anotamos con los decoradores:
@ ObjectType ( )
class Recipe {
@ Field ( type => ID )
id : string ;
@ Field ( )
title : string ;
@ Field ( type => [ Rate ] )
ratings : Rate [ ] ;
@ Field ( { nullable : true } )
averageRating ?: number ;
}Y obtenemos la parte correspondiente del esquema en SDL:
type Recipe {
id : ID !
title : String !
ratings : [ Rate ! ] !
averageRating : Float
}Luego podemos crear consultas, mutaciones y resolventes de campo. Para este propósito, utilizamos clases tipo controlador que se denominan "resonentes" por convención. También podemos usar características increíbles como inyección de dependencia y guardias de autores:
@ 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 ;
}
}Y de esta manera simple, obtenemos esta parte del esquema en SDL:
type Query {
recipes : [ Recipe ! ] !
}
type Mutation {
removeRecipe ( id : String ! ): Boolean !
}Todos sabemos que GraphQL es excelente y resuelve muchos problemas que tenemos con las API REST, como la exageración y la descomposición. Pero desarrollar una API GraphQL en Node.js con TypeScript a veces es un poco doloroso. ¿Por qué? Echemos un vistazo a los pasos que solemos dar.
Primero, creamos todos los tipos GraphQL en schema.graphql usando SDL. Luego creamos nuestros modelos de datos utilizando clases de ORM, que representan nuestras entidades DB. Luego comenzamos a escribir resonedores para nuestras consultas, mutaciones y campos, pero esto nos obliga a crear primero interfaces TS para todos los argumentos, entradas e incluso tipos de objetos.
Solo entonces podemos implementar los resonedores utilizando firmas genéricas extrañas y realizar tareas comunes manualmente, como validación, autorización y dependencias de carga:
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 } ) ;
} ;El mayor problema es la redundancia en nuestra base de código, lo que dificulta mantener las cosas sincronizadas. Para agregar un nuevo campo a nuestra entidad, tenemos que saltar a través de todos los archivos: modificar una clase de entidad, el esquema, así como la interfaz. Lo mismo ocurre con las entradas o argumentos. Es fácil olvidar actualizar una pieza o cometer un error con un solo tipo. Además, ¿qué pasa si hemos hecho un error tipográfico en el nombre del campo? La función de cambio de nombre (F2) no funcionará correctamente.
Herramientas como GraphQL Code Generator o GraphQLGen solo resuelven la primera parte: generan las interfaces correspondientes (y los esqueletos de los resonedores) para nuestro esquema GraphQL, pero no corrigen el esquema <--> Redundancia de los modelos y la experiencia del desarrollador (F2 Rename no funcionará, debe recordar sobre la tarea de vigilancia Codegen en el fondo, etc., así como las tareas comunes como la validación, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, la autorización, debe recordar sobre la tarea de vigilancia de Codegen.
TypeGraphQL llega a abordar estos problemas, basado en la experiencia de unos pocos años de desarrollo de API GraphQL en TypeScript. La idea principal es tener solo una fuente de verdad definiendo el esquema usando clases y algo de ayuda de los decoradores. Las características adicionales como inyección de dependencia, validación y guardias de autores ayudan con tareas comunes que normalmente tendríamos que manejarnos.
La documentación, la guía de instalación y la descripción detallada de la API y todas sus características están disponibles en el sitio web.
Se puede encontrar una guía completa para comenzar con un tutorial simple (tutorial) al comenzar los documentos.
Si prefiere tutoriales en video, puede ver la serie de videos TypeGraphql de Ben Awad en YouTube.
También puede verificar la carpeta de ejemplos en este repositorio para obtener más ejemplos de uso: resueltos de campos simples, soporte de contenedores DI, integración de tipormentos, validación automática, etc.
La carpeta de pruebas también puede darle algunos consejos sobre cómo hacer varias cosas.
Para informar una vulnerabilidad de seguridad, utilice el contacto de seguridad de TidElift. TidElift coordinará la solución y la divulgación.
La versión lanzada actualmente es una versión estable 1.0.0. Está bien probado (97% de cobertura, ~ 500 casos de prueba) y tiene la mayoría de las características planificadas ya implementadas. Muchas empresas y desarrolladores independientes lo están utilizando en producción con éxito.
Sin embargo, también hay planes para muchas más funciones, como Mejor typeorm, Prisma y la integración de DataLoader, los decoradores personalizados y el soporte de anotaciones de metadatos: la lista completa de ideas está disponible en el repositorio de GitHub. También puede realizar un seguimiento del progreso del desarrollo en el tablero del proyecto.
Si tiene alguna solicitud de función interesante, ¡no dude en abrir un problema en GitHub para que podamos discutir eso!
TypeGraphQL es un proyecto de código abierto licenciado por el MIT. Este marco es el resultado de la tremenda cantidad de trabajo: noches de insomnio, tardes ocupadas y fines de semana.
No tiene una gran empresa que se sienta detrás de él: su desarrollo continuo solo es posible gracias al apoyo de la comunidad.
Solicite a su empresa que apoye este proyecto de código abierto convirtiéndose en un patrocinador de oro y obteniendo un soporte técnico premium de nuestros contribuyentes principales.
