type-graphql
Advanced tools
Comparing version 1.0.0-rc.3 to 1.0.0
{ | ||
"name": "type-graphql", | ||
"version": "1.0.0-rc.3", | ||
"version": "1.0.0", | ||
"author": { | ||
@@ -25,34 +25,36 @@ "name": "Michał Lytek", | ||
"peerDependencies": { | ||
"graphql": "^15.1.0", | ||
"graphql": "^15.3.0", | ||
"class-validator": ">=0.12.0" | ||
}, | ||
"dependencies": { | ||
"@types/glob": "^7.1.2", | ||
"@types/glob": "^7.1.3", | ||
"@types/node": "*", | ||
"@types/semver": "^7.2.0", | ||
"@types/semver": "^7.3.3", | ||
"glob": "^7.1.6", | ||
"graphql-query-complexity": "^0.6.0", | ||
"graphql-query-complexity": "^0.7.0", | ||
"graphql-subscriptions": "^1.1.0", | ||
"semver": "^7.3.2", | ||
"tslib": "^2.0.0" | ||
"tslib": "^2.0.1" | ||
}, | ||
"devDependencies": { | ||
"@apollo/federation": "^0.16.4", | ||
"@apollo/gateway": "^0.16.4", | ||
"@typegoose/typegoose": "^7.2.0", | ||
"@apollo/federation": "^0.19.1", | ||
"@apollo/gateway": "^0.19.1", | ||
"@graphql-modules/core": "^0.7.17", | ||
"@graphql-modules/di": "^0.7.17", | ||
"@typegoose/typegoose": "^7.3.2", | ||
"@types/gulp": "^4.0.6", | ||
"@types/gulp-replace": "0.0.31", | ||
"@types/ioredis": "^4.16.4", | ||
"@types/jest": "^25.2.3", | ||
"@types/mongoose": "^5.7.23", | ||
"@types/node": "^14.0.11", | ||
"@types/ioredis": "^4.17.3", | ||
"@types/jest": "^26.0.10", | ||
"@types/mongoose": "^5.7.36", | ||
"@types/node": "^14.6.0", | ||
"@types/rimraf": "^3.0.0", | ||
"apollo-cache-control": "^0.11.0", | ||
"apollo-server": "^2.14.2", | ||
"class-transformer": "^0.2.3", | ||
"apollo-cache-control": "^0.11.1", | ||
"apollo-server": "^2.16.1", | ||
"class-transformer": "^0.3.1", | ||
"class-validator": "^0.12.2", | ||
"del": "^5.1.0", | ||
"graphql": "^15.1.0", | ||
"graphql-redis-subscriptions": "^2.2.1", | ||
"graphql-tag": "^2.10.3", | ||
"graphql": "^15.3.0", | ||
"graphql-redis-subscriptions": "^2.2.2", | ||
"graphql-tag": "^2.11.0", | ||
"gulp-replace": "^1.0.0", | ||
@@ -64,12 +66,12 @@ "gulp-shell": "^0.8.0", | ||
"ioredis": "^4.17.3", | ||
"jest": "^26.0.1", | ||
"lint-staged": "^10.2.9", | ||
"mongoose": "^5.9.18", | ||
"mysql": "^2.18.1", | ||
"jest": "^26.4.0", | ||
"lint-staged": "^10.2.11", | ||
"mongoose": "^5.10.0", | ||
"pg": "^8.3.2", | ||
"prettier": "^2.0.5", | ||
"reflect-metadata": "^0.1.13", | ||
"rimraf": "^3.0.2", | ||
"ts-jest": "^26.1.0", | ||
"ts-jest": "^26.2.0", | ||
"ts-node": "^8.10.2", | ||
"tslint": "^6.1.2", | ||
"tslint": "^6.1.3", | ||
"tslint-config-prettier": "^1.18.0", | ||
@@ -80,3 +82,3 @@ "tslint-eslint-rules": "^5.4.0", | ||
"typeorm-typedi-extensions": "^0.2.3", | ||
"typescript": "~3.9.5" | ||
"typescript": "~3.9.7" | ||
}, | ||
@@ -83,0 +85,0 @@ "husky": { |
@@ -19,35 +19,5 @@ ![logo](https://raw.githubusercontent.com/MichalLytek/type-graphql/master/img/logo.png) | ||
## 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](https://github.com/typeorm/typeorm), 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: | ||
```js | ||
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](https://github.com/dotansimha/graphql-code-generator) or [graphqlgen](https://github.com/prisma/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. | ||
## Introduction | ||
As mentioned, **TypeGraphQL** makes developing GraphQL APIs an enjoyable process, i.e. by defining the schema using only classes and a bit of decorator magic. | ||
**TypeGraphQL** makes developing GraphQL APIs an enjoyable process, i.e. by defining the schema using only classes and a bit of decorator magic. | ||
@@ -123,10 +93,32 @@ So, to create types like object type or input type, we use a kind of DTO classes. | ||
## Getting started | ||
## Motivation | ||
A full getting started guide with a simple walkthrough (tutorial) can be found at [getting started docs](https://typegraphql.com/docs/getting-started.html). | ||
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. | ||
## Video tutorial | ||
First, we create all the GraphQL types in `schema.gql` using SDL. Then we create our data models using [ORM classes](https://github.com/typeorm/typeorm), 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. | ||
If you prefer video tutorials, you can watch [Ben Awad](https://github.com/benawad)'s [TypeGraphQL video series](https://www.youtube.com/playlist?list=PLN3n1USn4xlma1bBu3Tloe4NyYn9Ko8Gs) on YouTube. | ||
Only then can we actually implement the resolvers using weird generic signatures and manually performing common tasks, like validation, authorization and loading dependencies: | ||
```js | ||
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](https://github.com/dotansimha/graphql-code-generator) or [graphqlgen](https://github.com/prisma/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 | ||
@@ -136,4 +128,12 @@ | ||
## Examples | ||
### Getting started | ||
A full getting started guide with a simple walkthrough (tutorial) can be found at [getting started docs](https://typegraphql.com/docs/getting-started.html). | ||
### Video tutorial | ||
If you prefer video tutorials, you can watch [Ben Awad](https://github.com/benawad)'s [TypeGraphQL video series](https://www.youtube.com/playlist?list=PLN3n1USn4xlma1bBu3Tloe4NyYn9Ko8Gs) on YouTube. | ||
### Examples | ||
You can also check the [examples folder](https://github.com/MichalLytek/type-graphql/tree/master/examples) in this repository for more examples of usage: simple fields resolvers, DI Container support, TypeORM integration, automatic validation, etc. | ||
@@ -143,12 +143,10 @@ | ||
## Towards v1.0 | ||
## The future | ||
The currently released version is a MVP (Minimum Viable Product). It is well tested (96% coverage, 8000 lines of test code) and has 95% of the planned features already implemented. | ||
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's still work to be done before the [1.0.0 release](https://github.com/MichalLytek/type-graphql/milestone/3) and it's mostly about documentation (website, api reference and jsdoc) and compatibility with the GraphQL spec and other tools. | ||
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](https://github.com/MichalLytek/type-graphql/issues?q=is%3Aissue+is%3Aopen+label%3A"Enhancement+%3Anew%3A") is available on the GitHub repo. You can also keep track of [development's progress on project board](https://github.com/MichalLytek/type-graphql/projects/1). | ||
There are also plans for more features like better TypeORM, Prisma and dataloader integration, custom decorators and metadata annotations support - [the full list of ideas](https://github.com/MichalLytek/type-graphql/issues?q=is%3Aissue+is%3Aopen+label%3A"Enhancement+%3Anew%3A") is available on the GitHub repo. You can also keep track of [development's progress on project board](https://github.com/MichalLytek/type-graphql/projects/1). | ||
If you have any interesting feature requests, feel free to open an issue on GitHub so we can discuss that! | ||
I encourage you to give TypeGraphQL a try and experiment with. If you have any questions, you can [ask on gitter](https://gitter.im/type-graphql/Lobby). If you find a bug, please report it as an issue on GitHub. If you have any interesting feature requests, I would be happy to hear about them. | ||
## Support | ||
@@ -191,2 +189,7 @@ | ||
If you have any questions, you can [ask on gitter](https://gitter.im/type-graphql/Lobby). | ||
If you find a bug, please report it as an issue on GitHub. | ||
If you want to add a new big feature, please create a proposal first, where we can discuss the idea and implementation details. This will prevent wasted time if the PR be rejected. | ||
PRs are welcome, but first check, test and build your code before committing it. | ||
@@ -196,3 +199,1 @@ | ||
- [Allowing changes to a pull request branch created from a fork](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) | ||
If you want to add a new big feature, please create a proposal first, where we can discuss the idea and implementation details. This will prevent wasted time if the PR be rejected. |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Deprecated
MaintenanceThe maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed.
Found 1 instance in 1 package
No v1
QualityPackage is not semver >=1. This means it is not stable and does not support ^ ranges.
Found 1 instance in 1 package
0
1
194
197863
42
+ Addedgraphql-query-complexity@0.7.2(transitive)
- Removedgraphql-query-complexity@0.6.0(transitive)
Updated@types/glob@^7.1.3
Updated@types/semver@^7.3.3
Updatedtslib@^2.0.1