question: AWS Lambda get pretty slow when using decorators

[sebastianroming]

I'm using class-validator in my newly created AWS lambda.
When using the property decorators provided, like @IsString(), the lambda gets painfully slow when invoking locally (~150ms without decorators, ~4000ms with decorators).

I'm not even validating the incoming object, just the fact the decorators are present slow down the lambda (as you may see):

lambda handler (handler.ts)

export const serviceRequestsHandler = async (event: APIGatewayProxyEvent & { body: RequestBody, queryStringParameters: RequestQueryString }): Promise<APIGatewayProxyResult> => {

  const parsedBody: RequestBody                   = new RequestBody(event.body);

  return new ResponseFactory().statusCode(204)
                              .body(null)
							  .factory();
};

RequestUser.ts

import { IsString } from 'class-validator';

export class RequestBody {

  @IsString()
  contact_person: string;

  @IsString()
  machine_identifier_customer: string;

  @IsString()
  message: string;

  constructor(request_body: RequestBody) {
    this.contact_person              = request_body.contact_person;
    this.machine_identifier_customer = request_body.machine_identifier_customer;
    this.message                     = request_body.message;
  }

}

As you can see, no hard work is done here what could cause an increase of ~4000ms, and no validation of the event.body object itself.
If I get rid of the decorators, runtime decreases, as mentioned, to about ~150ms.

Anyone has a guess what could cause this?

Thanks!

[NoNameProvided]

I don't provide support about how to use AWS.

If the issue still persists, you may open a new Q&A in the discussions tab and maybe someone from the community may be able to help.

[ajwootto]

@NoNameProvided we're actually running into this as well with Cloudflare Workers, and I think it's a good problem to think about that is more specific to the way the library works inside of "serverless functions" (not specifically AWS).

Basically I believe this library is performing a lot of work on startup to build the schemas for validation based on the class decorators. Normally that's fine in a long-running server application, but it seriously harms performance in a serverless function that starts up once in an isolated memory space, initializes all the schema stuff, does a little bit of work and then shuts down.

The only way around this that I could see would be to provide a way to take the class definitions and "precompute" the schemas as part of the build process (webpack etc.). If the library had some generalized support for that kind of thing it would be pretty useful I think.

[NoNameProvided]

Hi @ajwootto!

Thanks for the reply. Since this is nonactionable feedback ("it slow but no metrics") I cannot act on it. As a result please open a feature idea discussion where you

• explain what is wrong
• provide your use case (how and many class you decorate, what kind of data you validate)
• provide some statistics on what is slow and how many items you use
• write your idea about how this can be solved

After this, the community can iterate on the idea, discuss the next steps and when we know what we should do we can open a feature or fix the issue.

Basically I believe this library is performing a lot of work on startup to build the schemas for validation based on the class decorators.

I suspect something else is at play here, it should be not noticeable to build the metadata even if you have significant amount of decorated classes.

The only way around this that I could see would be to provide a way to take the class definitions and "precompute" the schemas as part of the build process (webpack etc.).

This is actually planned. class-validator should be able to emit its metadata in a serializable way. My initial idea was that this can be used for sharing the same validation logic between servers and or frontend, but it fits well your use case as well. However, it's important to note that this won't be implemented quickly, as first I need to get this repo in order. (See #1775 for details.)

[Shereef]

@NoNameProvided I am willing to have a crack at implementing this next week if you give me some advice on how you think it can be done

We are also using aws lambda and performance is paramount for us.

I agree #1775 is much more important so please focus on that and release what you have today ASAP so that snyk and re-evaluate and remove the vulnerability warning

Please and thanks!

[NoNameProvided]

First, we need to understand what is slow in class-validator when running in Lambda, and why it is slow.

If I would take a look at it, I would start by running my test cases with the NodeJS debugger attached and analyze the results of a few runs with profiling. The resulting flame graph will tell you when the most time is spent.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.