Add lazy compiling of validators

[sashee]

The library does as much as possible during init, which is great when it's deployed on a server that handles a lot of calls, but it's terrible for a serverless environment. I noticed 6-10 seconds of cold start times even for a small number of paths running on AWS Lambda, which is either makes the first request painfully slow or makes me increase the resources available to the function which makes it more expensive.

After a bit of investigation I found that most of the time is spent initializing the validators. I noticed that they are all pre-compiled (for example here). My hunch is that if these schemas are compiled lazily then the response time for the first request could be distributed in subsequent requests, making the library work better with serverless.

I'm wondering if you are open to a PR that add a new parameter (or reuse the "quick" argument) that makes the validator to not precompile the schemas on init.

[elby22]

@sashee I'm looking at some of the validator compile code at the moment. To accomplish lazy validators, my approach would probably to make the validateRequest (and similar methods) return Promise<ValidationResult>. If you want to front-load that compile time, you can simply Promise.all the validators in the main init function.
Thoughts?

[sashee]

@elby22 , I was thinking a bit more simplified version.

When the OpenAPIBackend's init is run, it constructs an OpenAPIValidator object: https://github.com/anttiviljami/openapi-backend/blob/master/src/backend.ts#L206

This in turn builds all the schemas it finds in the document (and a few more), like here: https://github.com/anttiviljami/openapi-backend/blob/24ca22f3bc800a52c2dcf9a08e75736f01e6fe3d/src/validation.ts#L173

And these schemas are compiled as part of the init function: https://github.com/anttiviljami/openapi-backend/blob/24ca22f3bc800a52c2dcf9a08e75736f01e6fe3d/src/validation.ts#L478

My thinking is that this compile call could be deferred until the resulting function (the compiled validator) is needed. By this, I believe the bulk of the work can be moved to later requests. And all with maintaining the current, synchronous, interface.

[anttiviljami]

@sashee something like this would be awesome 💪 definitely needed

[anttiviljami]

Hi @sashee @elby22 ! Would this solution work for you?

#141

[sashee]

@anttiviljami , wow, I didn't expect you go ahead and implement it. Seems great!

I tested the branch with a demo project of mine (https://github.com/sashee/openapi_lambda) and here are the results:

I made some requests, listing objects twice, creating a new one, deleting the new one, then listing again. I believe the extra 2 requests are CORS preflights (the short ones)

Version 3.6.3, quick: true: (all values are in milliseconds, each one corresponds to one request)
2339, 119, 41, 53, 1, 54, 41

Branch, quick: true: (the same requests)
814, 297, 71, 270, 2, 113, 32

It shows that the first request is definitely shorter with the changes and the work is distributed to the later requests. I believe this is more pronounced with more operations but right now I only have a small test project.

Overall, it looks great!

[anttiviljami]

Awesome! I'll then go ahead and merge this. I'll probably need to release a new major version due to some other pending stuff in the master branch.

I believe further optimisation for serverless use cases would still be useful. In my tests, just importing some of the dependencies seems (mostly swagger-parser) takes a significant amount of time during lambda cold start.