Feature Request: Exception Handling

[cloudcompute]

This code involves 3 things: a. GraphQL support b. Nest JS c. Prisma All of them have their own built-in support for exceptions and errors.

Can we write the Exception handling together? I'd write the basic code and expect that someone among you help take the code to a 'production-ready" state?

[marcjulian]

@ramandhingra This sounds like a great idea! You can create an ExceptionFilter catching all PrismaClientKnownRequestError and creating different responses based on the error codes.

If you like you can follow my recent workshop on NestJS and Prisma where I talked about creating an exception filter for Nest and Prisma. If you need any help let me know.

[cloudcompute]

@marcjulian

Thank you for the response. I had a quick look at your workshop's exception filter. My idea is a bit different than you. Pl. give me few days and I'll write about it in detail.

[marcjulian]

@ramandhingra closing for now! Feel free to open again if you like to come back to this

[cloudcompute]

Hi @marcjulian

I decided not to use NestJS for several reasons.

• Throwing different types of NestJS exceptions from the service layer and then converting them to some standard Error interface before sending it to the client meaning more work.

• Getting access to the underlying express instance in NestJS is not straightforward.

• NestJS has built an extra layer on top of the existing npm packages, for example nestjs/logging, nestjs/bull. Now if, let's say, the bull npm is updated to a new version, we need to wait till the maintainers of the nestjs/bull updates their code and use the new version of bull.

• Similarly, writing NestJS Modules is an extra burden. Using ExpressJS or Fastify are fairly simple. Big projects are using them in production. There exist great libraries like Inversify (dependency injection), node-config which we can use for the features that Express and Fastify don't offer by default.

• I am almost sure a NestJS application will consume more memory than Express based apps.

• This starter kit is using the class-validator package which lets us apply the validations using decorators. If we use this validation approach on the server side, we cannot probably use the same validation code on the client-side. While a zod-like validation library could be used to share the same code among the client and server.

This kit is not intended for the serverless environment, we can deploy them on a dedicated server only. But I am looking forward to deploy the applications on serverless backends. Reasons a. Using a dedicated server is costlier than the serverless b. We need to administer the dedicated server ourselves making sure it is always running and find out ways for its efficient performance if there is a sudden increase in the traffic.

But I learned a lot from this starter kit, the best thing is how JWTs can be used to keep the server stateless. Thank you for the time that you devote to the community. I am sure many must be using this kit in their projects. When I came across this kit for the first time, 545 stars were there and now the figure has doubled.

I have a question relating to JWT, could you pl. answer? There is a mutation named, refreshToken() which is exposed as an endpoint. In the documentation, there is no mention about when to make a call to this endpoint? Over there, it is just stated that send the token in the Authorization header.