Back to Tutorials
6 min read

Scalar types in GraphQL

With GraphQL, we model our API as a graph. Within a schema, we have various types of nodes that can relate to each other. While the fields in our query might…

February 22, 2021

With GraphQL, we model our API as a graph. Within a schema, we have various types of nodes that can relate to each other. While the fields in our query might have sub-fields, at some point, we want to work on concrete data. We refer to the type that describes an individual value as the scalar. It does not have any sub-fields and represents a leaf in the graph. In some way, scalars are similar to primitive values.

A leaf in a graph is a node that does not have any children

GraphQL supports a set of scalar types out of the box:

  • Int: a signed 32-bit integer
    • can’t hold fractional values,
  • Float: signed double-precision floating-point value,
    • can hold fractional values,
  • Boolean: either true or false,
  • ID: represents a unique identifier, serialized in the same way as String.

Scalar types in NestJS#

We’ve already used some of the above in the previous parts of this series.

post.model.ts#
import { Field, Int, ObjectType } from "@nestjs/graphql"
import { User } from "../../users/models/user.model"
@ObjectType()
export class Post {
  @Field(() => Int)
  id: number
  @Field()
  title: string
  @Field(() => [String])
  paragraphs: string[]
  @Field(() => Int)
  authorId: number
  @Field()
  author: User
}

An important thing to look into above is how we use the @Field() decorator. We don’t have to specify the exact scalar type for strings and booleans. Since we can represent numbers either as an Int or Float, we should pass an additional parameter to the @Field() decorator.

If we don’t pass the parameter with the type, NestJS by default would use the Float scalar. We could change this behaviour by setting the numberScalarMode parameter to integer.

Handling dates with NestJS and TypeORM#

Under the hood, NestJS implements additional scalars that we should be aware of:

  • GraphQLISODateTime: a date-time UTC string,
    • NestJS uses it by default to represent the Date type,
  • GraphQLTimestamp: a numeric string representing the time and date as the number of milliseconds from the start of the UNIX epoch,
    • we can use it instead of GraphQLISODateTime.

To observe the behavior of GraphQLISODateTime and GraphQLTimestamp, let’s add a field to our PostEntity.

So far in this series, we’ve been using TypeORM. In the documentation, we can see that it has a @CreateDateColumn() decorator. It allows us to access the entity’s insertion time. TypeORM sets its value under the hood.

post.entity.ts#
import { Entity, PrimaryGeneratedColumn, CreateDateColumn } from "typeorm"
@Entity()
class Post {
  @PrimaryGeneratedColumn()
  public id: number
  @CreateDateColumn({ type: "timestamp" })
  createdAt: Date // ...
}
export default Post

The last thing to do is to modify our model:

post.model.ts#
import { Field, Int, ObjectType } from "@nestjs/graphql"
@ObjectType()
export class Post {
  @Field(() => Int)
  id: number
  @Field()
  createdAt: Date // ...
}

Thanks to doing all of the above, we can now query the creation date of our posts.

By default, NestJS used the custom GraphQLISODateTime scalar. We could change this behavior and use timestamps instead by setting the dateScalarMode option.

app.module.ts#
import { Module } from "@nestjs/common"
import { ConfigModule, ConfigService } from "@nestjs/config"
import { GraphQLModule } from "@nestjs/graphql"
import { join } from "path"
@Module({
  imports: [
    GraphQLModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (configService: ConfigService) => ({
        playground: Boolean(configService.get("GRAPHQL_PLAYGROUND")),
        autoSchemaFile: join(process.cwd(), "src/schema.gql"),
        installSubscriptionHandlers: true,
        buildSchemaOptions: {
          dateScalarMode: "timestamp",
        },
      }),
    }), // ...
  ],
  controllers: [],
  providers: [],
})
export class AppModule {}

Defining custom scalars#

Aside from using the built-in types, we can also create our own scalars. As an example, let’s replicate the functionalities of the GraphQLTimestamp type.

To do that, we need to create a class that implements the CustomScalar interface. it consists of three methods:

  • serialize
    • its job is to parse the result when sending it to the client
  • parseValue
    • parses values received from the client during mutation provided as variables in a JSON format
  • parseLiteral
    • also parsers the values provided during mutation, but in the form of hard-coded values as a part of the Abstract Syntax Tree (AST)

Let’s mimic the Timestamp scalar that NestJS has under the hood:

timestamp.scalar.ts#
import { Scalar, CustomScalar } from "@nestjs/graphql"
import { Kind, ValueNode } from "graphql"
@Scalar("Timestamp", () => Date)
export class Timestamp implements CustomScalar<number, Date> {
  description =
    "`Date` type as integer. Type represents date and time as number of milliseconds from start of UNIX epoch."
  serialize(value: Date) {
    return value instanceof Date ? value.getTime() : null
  }
  parseValue(value: string | number | null) {
    try {
      const number = Number(value)
      return value !== null ? new Date(number) : null
    } catch {
      return null
    }
  }
  parseLiteral(valueNode: ValueNode) {
    if (valueNode.kind === Kind.INT || valueNode.kind === Kind.STRING) {
      try {
        const number = Number(valueNode.value)
        return new Date(number)
      } catch {
        return null
      }
    }
    return null
  }
}

We also need to add the Timestamp scalar to the providers array in our AppModule.

Above, we should look a bit deeper into the parseLiteral method. Its argument is of the type ValueNode and describes the input that the user added in the mutation.

To check its type, we need to compare the valueNode.kind with the Kind exported with the graphql library.

Testing our Timestamp scalar#

To create a valid use case for parseValue and parseLiteral, let’s add a date field that the client can set. An example of that could be scheduledDate in the Post entity.

post.entity.ts#
import { Column, Entity, PrimaryGeneratedColumn, CreateDateColumn } from "typeorm"
@Entity()
class Post {
  @PrimaryGeneratedColumn()
  public id: number
  @CreateDateColumn({ type: "timestamp" })
  createdAt: Date
  @Column({
    type: "timestamp",
    nullable: true,
  })
  scheduledDate?: Date
}
export default Post

We also need to add the new field to the model and the input.

post.model.ts#
import { Field, Int, ObjectType } from "@nestjs/graphql"
@ObjectType()
export class Post {
  @Field(() => Int)
  id: number
  @Field()
  createdAt: Date
  @Field({ nullable: true })
  scheduledDate?: Date // ...
}
post.input.ts#
import { InputType, Field } from "@nestjs/graphql"
@InputType()
export class CreatePostInput {
  @Field()
  title: string
  @Field(() => [String])
  paragraphs: string[]
  @Field({ nullable: true })
  scheduledDate?: Date
}

First, let’s try out the parseLiteral method. To do that, we need to create a mutation while hardcoding the values:

Performing the above mutation causes the parseLiteral method to run with the following argument:

{
  type: Kind.INT,
  value: 1613919356099
}

To test the parseValue method, we need to pass the values as a set of variables:

Summary#

In this article, we’ve looked into scalar types in GraphQL and how to apply them in NestJS. We’ve gone through both the basic scalars and the custom ones built into NestJS. On top of that, we’ve created our own custom scalar. By doing so, we’ve got to know the difference between sending the mutation input with variables and inline values.

Scalar types in GraphQL | NestJS.io