Upfront initialization of path params & other expensive work

[patricktyndall]

Is your feature request related to a problem? Please describe. See discussion here. Even after the library is initialized, there is a separate "cold start" which occurs on the first request. For those of us in a serverless architecture, this makes the impact of this library more diffcult to measure / solve with standard tools like provisioned concurrency - a "warm" container might still incur this cost.

• As seen in the linked issue, the pathParamsMiddleware alone can incur a >400ms cost when it initializes. requestMiddleware also implicated.

Describe the solution you'd like An option to .init() an instance before the first request, to frontload all that expensive work. E.g. to imperatively trigger the initialization that is done here and here.

Describe alternatives you've considered I guess the alternative would be to trigger a "dummy" request against the app instance? Seems ugly.

Additional context More context / converstaion available on the discussion here

Thanks! Keywords: Lambda, serverless, cold start, initialization, init, performance, latency

[cdimascio]

hi @patricktyndall, here is a thought to eagerly invoke the middleware on startup using the eov as-is. The idea is to initialize the middleware as normal. however, proactively trigger it using a mock request

Let me know how it goes

// Create a mock request which we'll eager invoke to force the middleware to run
// We arbitrarily choose GET /v1/pets
const mockReq = {
  method: 'GET',
  url: '/v1/pets',
  originalUrl: '/v1/pets',
  path: '/v1/pets',
  headers: {},
  body: {},
  query: {},
  params: {},
  app,
};

// 1. Initialize middleware
const oav = OpenApiValidator.middleware({ apiSpec });

// 2. Proactively run the validator middleware using the mockReq
oav.forEach(o => o(mockReq, {}, (req, res, next) => console.log('Middleware has finished running')));

// 3. Install the OpenApiValidator on your express app
app.use(oav);

// NOTE: 2. and 3. can be done in any order

[patricktyndall]

Thanks @cdimascio that's helpful. I'll let you know when give it a try.

I personally still think this library should expose this / this should not be necessary in future (I'd argue it should be the lib's default behavior, an option, or at least an officially documented approach).

I really appreciate the example code and will incorporate soon. This will definitely help eliminate variables when profiling other middleware slowness.