Scalars

A GraphQL object type has a name and fields, but at some point those fields have to resolve to some concrete data. That’s where the scalar types come in: they represent the leaves of the query (read more here). GraphQL includes the following default types: Int, Float, String, Boolean and ID. In addition to these built-in types, you may need to support custom atomic data types (e.g., Date).

Code first

The code-first approach ships with five scalars in which three of them are simple aliases for the existing GraphQL types.

  • ID (alias for GraphQLID) - represents a unique identifier, often used to refetch an object or as the key for a cache
  • Int (alias for GraphQLInt) - a signed 32‐bit integer
  • Float (alias for GraphQLFloat) - a signed double-precision floating-point value
  • GraphQLISODateTime - a date-time string at UTC (used by default to represent Date type)
  • GraphQLTimestamp - a numeric string which represents time and date as number of milliseconds from start of UNIX epoch

The GraphQLISODateTime (e.g. 2019-12-03T09:54:33Z) is used by default to represent the Date type. To use the GraphQLTimestamp instead, set the dateScalarMode of the buildSchemaOptions object to 'timestamp' as follows:

  1. GraphQLModule.forRoot({
  2. buildSchemaOptions: {
  3. dateScalarMode: 'timestamp',
  4. }
  5. }),

Likewise, the GraphQLFloat is used by default to represent the number type. To use the GraphQLInt instead, set the numberScalarMode of the buildSchemaOptions object to 'integer' as follows:

  1. GraphQLModule.forRoot({
  2. buildSchemaOptions: {
  3. numberScalarMode: 'integer',
  4. }
  5. }),

In addition, you can create custom scalars. For example, to create a Date scalar, simply create a new class.

  1. import { Scalar, CustomScalar } from '@nestjs/graphql';
  2. import { Kind, ValueNode } from 'graphql';
  3. @Scalar('Date', (type) => Date)
  4. export class DateScalar implements CustomScalar<number, Date> {
  5. description = 'Date custom scalar type';
  6. parseValue(value: number): Date {
  7. return new Date(value); // value from the client
  8. }
  9. serialize(value: Date): number {
  10. return value.getTime(); // value sent to the client
  11. }
  12. parseLiteral(ast: ValueNode): Date {
  13. if (ast.kind === Kind.INT) {
  14. return new Date(ast.value);
  15. }
  16. return null;
  17. }
  18. }

With this in place, register DateScalar as a provider.

  1. @Module({
  2. providers: [DateScalar],
  3. })
  4. export class CommonModule {}

Now we can use the Date type in our classes.

  1. @Field()
  2. creationDate: Date;

Schema first

To define a custom scalar (read more about scalars here), create a type definition and a dedicated resolver. Here (as in the official documentation), we’ll use the graphql-type-json package for demonstration purposes. This npm package defines a JSON GraphQL scalar type.

Start by installing the package:

  1. $ npm i --save graphql-type-json

Once the package is installed, we pass a custom resolver to the forRoot() method:

  1. import GraphQLJSON from 'graphql-type-json';
  2. @Module({
  3. imports: [
  4. GraphQLModule.forRoot({
  5. typePaths: ['./**/*.graphql'],
  6. resolvers: { JSON: GraphQLJSON },
  7. }),
  8. ],
  9. })
  10. export class AppModule {}

Now we can use the JSON scalar in our type definitions:

  1. scalar JSON
  2. type Foo {
  3. field: JSON
  4. }

Another method to define a scalar type is to create a simple class. Assume we want to enhance our schema with the Date type.

  1. import { Scalar, CustomScalar } from '@nestjs/graphql';
  2. import { Kind, ValueNode } from 'graphql';
  3. @Scalar('Date')
  4. export class DateScalar implements CustomScalar<number, Date> {
  5. description = 'Date custom scalar type';
  6. parseValue(value: number): Date {
  7. return new Date(value); // value from the client
  8. }
  9. serialize(value: Date): number {
  10. return value.getTime(); // value sent to the client
  11. }
  12. parseLiteral(ast: ValueNode): Date {
  13. if (ast.kind === Kind.INT) {
  14. return new Date(ast.value);
  15. }
  16. return null;
  17. }
  18. }

With this in place, register DateScalar as a provider.

  1. @Module({
  2. providers: [DateScalar],
  3. })
  4. export class CommonModule {}

Now we can use the Date scalar in type definitions.

  1. scalar Date

By default, the generated TypeScript definition for all scalars is any - which isn’t particularly typesafe. But, you can configure how Nest generates typings for your custom scalars when you specify how to generate types:

  1. import { GraphQLDefinitionsFactory } from '@nestjs/graphql';
  2. import { join } from 'path';
  3. const definitionsFactory = new GraphQLDefinitionsFactory()
  4. definitionsFactory.generate({
  5. typePaths: ['./src/**/*.graphql'],
  6. path: join(process.cwd(), 'src/graphql.ts'),
  7. outputAs: 'class',
  8. defaultScalarType: 'unknown',
  9. customScalarTypeMapping: {
  10. DateTime: 'Date',
  11. BigNumber: '_BigNumber',
  12. },
  13. additionalHeader: "import _BigNumber from 'bignumber.js'",
  14. })

info Hint Alternatively, you can use a type reference instead, for example: DateTime: Date. In this case, GraphQLDefinitionsFactory will extract the name property of the specified type (Date.name) to generate TS definitions. Note: adding an import statement for non-built-in types (custom types) is required.

Now, given the following GraphQL custom scalar types:

  1. scalar DateTime
  2. scalar BigNumber
  3. scalar Payload

We will now see the following generated TypeScript definitions in src/graphql.ts:

  1. import _BigNumber from 'bignumber.js'
  2. export type DateTime = Date
  3. export type BigNumber = _BigNumber
  4. export type Payload = unknown

Here, we’ve used the customScalarTypeMapping property to supply a map of the types we wish to declare for our custom scalars. We’ve also provided an additionalHeader property so that we can add any imports required for these type definitions. Lastly, we’ve added a defaultScalarType of 'unknown', so that any custom scalars not specified in customScalarTypeMapping will be aliased to unknown instead of any (which TypeScript recommends using since 3.0 for added type safety).

info Hint Note that we’ve imported _BigNumber from bignumber.js; this is to avoid circular type references.