- 1. API with NestJS #1. Controllers, routing and the module structure
- 2. API with NestJS #2. Setting up a PostgreSQL database with TypeORM
- 3. API with NestJS #3. Authenticating users with bcrypt, Passport, JWT, and cookies
- 4. API with NestJS #4. Error handling and data validation
- 5. API with NestJS #5. Serializing the response with interceptors
- 6. API with NestJS #6. Looking into dependency injection and modules
- 7. API with NestJS #7. Creating relationships with Postgres and TypeORM
- 8. API with NestJS #8. Writing unit tests
- 9. API with NestJS #9. Testing services and controllers with integration tests
- 10. API with NestJS #10. Uploading public files to Amazon S3
- 11. API with NestJS #11. Managing private files with Amazon S3
- 12. API with NestJS #12. Introduction to Elasticsearch
- 13. API with NestJS #13. Implementing refresh tokens using JWT
- 14. API with NestJS #14. Improving performance of our Postgres database with indexes
- 15. API with NestJS #15. Defining transactions with PostgreSQL and TypeORM
- 16. API with NestJS #16. Using the array data type with PostgreSQL and TypeORM
- 17. API with NestJS #17. Offset and keyset pagination with PostgreSQL and TypeORM
- 18. API with NestJS #18. Exploring the idea of microservices
- 19. API with NestJS #19. Using RabbitMQ to communicate with microservices
- 20. API with NestJS #20. Communicating with microservices using the gRPC framework
- 21. API with NestJS #21. An introduction to CQRS
- 22. API with NestJS #22. Storing JSON with PostgreSQL and TypeORM
- 23. API with NestJS #23. Implementing in-memory cache to increase the performance
- 24. API with NestJS #24. Cache with Redis. Running the app in a Node.js cluster
- 25. API with NestJS #25. Sending scheduled emails with cron and Nodemailer
- 26. API with NestJS #26. Real-time chat with WebSockets
- 27. API with NestJS #27. Introduction to GraphQL. Queries, mutations, and authentication
- 28. API with NestJS #28. Dealing in the N + 1 problem in GraphQL
- 29. API with NestJS #29. Real-time updates with GraphQL subscriptions
- 30. API with NestJS #30. 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 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 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
1 2 3 4 5 6 7 8 9 10 11 12 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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
1 2 3 4 5 6 7 8 9 10 11 12 13 | 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:
1 2 3 4 | { 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.