perf(common): lazy load class validator and class transformer

[HGRon]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Currently the default behavior of the ValidatorPipe is to load the ClassValidator and the ClassTransformer as soon as the application starts, this took 35ms on my machine:

What is the new behavior?

Now the behavior has been modified so that it loads when receiving the first request.

Does this PR introduce a breaking change?

• Yes
• No

[coveralls]

Pull Request Test Coverage Report for Build 8ca218e2-352d-4c44-9118-20921fe4ab8e

• 10 of 10 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.007%) to 92.641%

---

Totals
Change from base Build ca6b0cd6-9a68-4f95-9278-bca8f4b87731:	0.007%
Covered Lines:	6534
Relevant Lines:	7053

---

💛 - Coveralls

[kamilmysliwiec]

Are we sure that it is better to speed up the bootstrap time by 35ms while slowing down the first request response?

[HGRon]

Yes @kamilmysliwiec, it's the same idea in this PR nestjs/swagger#2392. Basically benefits those who run serverless.

[kamilmysliwiec]

And what about the majority of users that don't run apps on serverless? Lazily initializing a document is a slightly different optimization - it wouldn't affect application's end-users but just developers (which is fine)

[HGRon]

Regardless of where you deploy a NestJS application, it's ideal to have it initialize as swiftly as possible to ensure prompt request handling.

Although a slower initial request doesn't heavily impact NestJS performance, a slightly delayed startup can be somewhat inconvenient.

Furthermore, not all routes necessitate the use of ValidationPipe. It's possible that the API's first incoming request is for a public route, causing the entire API to incur a penalty for that solitary route.

[kamilmysliwiec]

it's ideal to have it initialize as swiftly as possible to ensure prompt request handling.

I'd rather say it's ideal to have a fully functioning application - not a partial one that requires loading basic features (like validation) on demand. We don't really defer loading anything, that's the philosophy & a reason why features like async providers were introduced in the first place.

[H4ad]

@kamilmysliwiec Don't it worth at least having an option for the user, something like lazyInitialize? By default false to keep the default behavior and serverless users can enable to get a little bit better performance on startup.