Type-graphql: Error codes

[Lurk]

Is your feature request related to a problem? Please describe.

auth-middleware throws UnauthorizedError or ForbiddenError which extend from Error.
That gives error code INTERNAL_SERVER_ERROR

{
  "errors": [
    {
      "message": "Access denied! You need to be authorized to perform this action!",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "user"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    }
  ],
  "data": {
    "user": null
  }
}

which are not useful

Describe the solution you'd like

can we use Apollo errors or implement something like that?

Describe alternatives you've considered
allow users to use custom auth-middleware

[MichalLytek]

You can use formatError to implement returning your own custom codes:
https://19majkel94.github.io/type-graphql/docs/next/validation.html#response-to-the-client

TypeGraphQL can't be coupled with apollo as it may be used with express-graphql or whatever server you want :wink:

[Lurk]

Thanks for formatError - it solves my problem.

But Apollo errors are just implementation of GraphQLError

import { GraphQLError, GraphQLFormattedError } from 'graphql';

export class ApolloError extends Error implements GraphQLError 

So no need to couple with Apollo. Errors should be proper implementation of GraphQLError.

[MichalLytek]

graphql-js wraps every error from resolver/middleware (UnauthorizedError or SQL error from ORM) into a GraphQLError - it places it under the originalError key. So I don't see a particular reason to throw GraphQLError in authChecker middleware.

If you don't like the built-in errors, you can just throw an error in your authChecker function 😉

[Lurk]

I am solved this particular issue with formatError (thank you again for the hint).
But, just errors without error codes don't make much sense.

Just saying :)

[MichalLytek]

just errors without error codes don't make much sense

I treat GraphQL errors like there are for developers only - to find a source of the bug your code.

If you client logic rely on the "error" (e.g. user with email already exist), it should be explicitly defined in schema in the return type of the query/field (e.g. as an union). This allows you to create a clean, self documenting API, instead of relying on non typesafe and internal representation of errors info.

[MichalLytek]

@Lurk
Looks like the extensions are not provided to the app code in apollo client, so it's definitely for development purpose, not the production usage in business logic:
https://github.com/apollographql/react-apollo/issues/2059

So closing for a housekeeping purposes 🔒
If there will be interest after 0.17 release, I may reintroduce the formatValidationErrors helper.

[MichaelHindley]

just errors without error codes don't make much sense

I treat GraphQL errors like there are for developers only - to find a source of the bug your code.

If you client logic rely on the "error" (e.g. user with email already exist), it should be explicitly defined in schema in the return type of the query/field (e.g. as an union). This allows you to create a clean, self documenting API, instead of relying on non typesafe and internal representation of errors info.

I've been trying to figure out how to use the class-validator integration together with createUnion and InputType for this, but I can't seem to figure it out based on the examples and my admitted lack of understanding the mechanisms deeply. Is this even possible to do without some nasty hacks?

[MichalLytek]

No, you unions in response type are for business logic "errors" - validation like (email is an email) should be done on client side too, so you won't receive validation error from your backend.

[MichaelHindley]

Thank you for clearing that up, that seems like a very sound pattern.

In my case the api is public or meant for consumption by a dozen other teams at BIGCO, so you don't have control of the client logic, in which case validation errors must be emitted by the backend, with localization, and be part of the schema for integration purposes, as it is with proper self exploring REST api's :) Just trying to figure out architecturally where GraphQL offers solutions to these problems, in the GQL way.

[MichalLytek]

So all I can think of now is to have a ArgumentsValidation object types that has a property errors of type JSON scalar (returns an object with unknown keys and value string), use this object types in all response unions and use a middleware to catch the typegraphql validation error and return it as an ArgumentsValidation object.