DEV Community: dmitryvz

Server-sent events in NestJS in depth

dmitryvz — Fri, 10 Nov 2023 08:46:32 +0000

Server-sent events (SSE) offer an efficient way to implement real-time updates in web applications by allowing servers to push data to connected clients.

Traditionally, a web page has to send a request to the server to receive new data; that is, the page requests data from the server. With server-sent events, it's possible for a server to send new data to a web page at any time, by pushing messages to the web page. (MDN)

In other words, the client establishes a permanent connection with the server, allowing the server to send data to the client. All modern browsers support SSE so you don't have to bring another JS library.

We use SSE at ClapDuel to update counters on page in real-time.

NestJS offers SSE out of box. Here is an example from the docs:

@Sse('sse')
sse(): Observable<any> {
  return interval(1000).pipe(map((_) => ({ data: { hello: 'world' } })));
}

Basically, you need to prepend controller action with @Sse decorator and return an observable(RxJs).

In a real application, you'll use SSE to send data when specific events occur. For instance, in a chat application, you'd send information about a new message to all connected users when a new message is posted.

In the context of NestJS, this means that a user is sending data to Action A while all users are connected to the SSE action. You need to inform the SSE action that something has happened in Action A. This can be done in many ways. In this article we will explore two solutions:

RxJs observables
EventEmitter

Here's an example that extends the one from the documentation, using observables:

private readonly sseStream = new Subject()

@Post()
actionA() {
  this.sseStream.next({type: 'new-message', data: 'Hello'})
}

@Sse('sse')
sse(): Observable<any> {
  return this.sseStream;
}

Although very simple, this approach has one major drawback - inside the SSE action the connection is already established, so, for example, you cannot decline the connection with a 403 or 404 error.

In next example we will implement SSE manually. Thanks to NestJS, manual implementation is made more straightforward with the built-in SseStream class.

@Get('sse')
sse(@Req() request, @Res() response) {
  const stream = new SseStream(request);
  return stream.pipe(response);
}

Note that we have replaced the @Sse decorator with the @Get decorator. Now we have full control over the request and response, making it possible to reject incoming requests and close connection with client if necessary.

SseStream class is just a transformational stream that will handle all headers required for SSE and will transform data you write in it into valid SSE message.

Now lets see how we can rewrite example using EventEmitter.

private readonly eventStream = new EventEmitter()

@Post()
actionA() {
  this.eventStream.emit('new-message', 'Hello')
}

@Get('sse')
sse(@Req() request, @Res() response) {
  const sseStream = new SseStream(request)
  this.eventStream.on('new-message', onNewMessage);
  response.on('close', () => {
    this.eventStream.off('new-message', onNewMessage)
  });
  return sseStream.pipe(response)

  function onNewMessage(data) {
    sseStream.write({type: 'new-message', data})
  }
}

Pay attention to the response.on('close') line, which is important for freeing up resources when the connection is closed. Don't worry if you encounter a MaxListenersExceededWarning: Possible EventEmitter memory leak detected warning.

Conclusion

NestJS simplifies the integration of SSE into your applications, offering both built-in support and manual implementation.

Using Yup to validate user input in a NestJS project

dmitryvz — Wed, 20 Sep 2023 18:17:24 +0000

This article assumes that you are familiar with NestJS framework.

The Importance of Validation
Validation is a crucial step in ensuring the integrity and security of your application. While NestJS documentation offers the class-validator library for validation, it can sometimes be challenging to work with. Lets explore an alternative validation approach using Yup in a NestJS project.

Using class-validator
In a typical NestJS project, you might define your DTOs (Data Transfer Objects) with class-validator decorators to perform validation. In my project users can submit posts with title and variable amount of teams. A team has one field - title. In accordance with Nestjs docs I created a DTO for post data and added validation to it:

class Team {
  @IsDefined({message: 'Bad request'})
  @IsString({message: 'Bad request'})
  @MinLength(TITLE_MIN_LENGTH, {
    message: 'Too short',
  })
  @MaxLength(TITLE_MAX_LENGTH, {
    message: 'Too long',
  })
  name: string;
}

class PostBody {
  @IsDefined({message: 'Bad request'})
  @IsString({message: 'Bad request'})
  @MinLength(TITLE_MIN_LENGTH, {
    message: 'Too short',
  })
  @MaxLength(TITLE_MAX_LENGTH, {
    message: 'Too long',
  })
  title: string;

  @IsDefined({message: 'Bad request'})
  @IsArray({message: 'Bad request'})
  @ArrayMinSize(MIN_TEAMS)
  @ArrayMaxSize(MAX_TEAMS)
  @ValidateNested()
  @Type(() => Team)
  teams: Team[];
}

Pretty hard to find where the real DTO is, huh?

My primary concern was that the ArrayMinSize and ArrayMaxSize validators were not functioning correctly. Users could submit any number of teams, and the DTO would still pass validation. This is a known issue with class-validator, and although workarounds exist, none of them seemed optimal.

Introducing Yup
After conducting some research I decided to switch to a library that works for all of my use cases out of box. I have looked at most popular validation libraries and found out that Yup covers all my needs:

Validates my DTOs.
Easy schema definition syntax.
Ability to incorporate error messages directly into validation rules.

Yup functions similarly to class-validator. It requires you to define validation rule schemas, allowing to separate the DTO from validation. The DTO is now a plain JavaScript object:

class PostBody {
  title: string;
  teams: Team[];
}

Validation rules can be defined as constants and can be reused across various validation scenarios. Lets define rule for validating title:

const titleSchema = string()
  .strict()
  .typeError('Bad request')
  .trim()
  .min(TITLE_MIN_LENGTH, `Too short`)
  .max(TITLE_MAX_LENGTH, `Too long`)

And now to the main point - validation for an array of objects:

const teamsSchema = array()
  .strict()
  .typeError('Bad request')
  .min(MIN_TEAMS, 'Bad request')
  .max(MAX_TEAMS, 'Bad request')
  .of(
    object({
      name: titleSchema,
    }),
  )

Schema for validating the entire post:

const postSchema = object({
  title: titleSchema,
  teams: teamsSchema,
})

Note the reuse of titleSchema in postSchema and in teamsSchema. DRY in action.

Declaring validation rules as constants enables us to create similar schemas without the need to redundantly redeclare the rules. For instance, we can define a "post create" schema that accepts all fields and a "post update" schema that accepts only the title field.

To integrate Yup validation into a NestJS project, we'll need a custom validation pipe:

class YupValidationPipe implements PipeTransform {
  constructor(private schema: ObjectSchema<any>) {}

  transform(value: any) {
    return this.schema.validateSync(value);
  }
}

Now we can use the YupValidationPipe in a controller action to validate incoming data easily:

async createPost(
  @GetUser() user: User, 
  @Body(new YupValidationPipe(postSchema)) post: PostBody
) { ... }

Conclusion
While initially seeking a library solely for required validation, my transition to Yup yielded unexpected advantages:

Cleaner and more concise DTO code.
Rule reusability.
Convenient error message handling within validation rules, facilitating user-friendly error displays (an uncommon feature in many libraries).

Of course, integrating Yup into my NestJS project required some additional effort, but it ultimately proved to be a more efficient solution compared to troubleshooting issues with class-validator.

Visit clapduel.com to see the code in action.