Cold Start Trick with new v4 module

I saw this interesting medium post based on aws-serverless-express that helps with cold-start in nestjs by moving the bootstrap part to the init stage and not within the handler, like shown below

Need help with translating this to the new v4 way of bootstrapping the express server using nestjs as the proxy is deprecated.

[Muthuveerappanv]

@Muthuveerappanv Did you figure it out?

Nope 😒

[samjmarshall]

Hey @Muthuveerappanv, after trying a few different implementations, I’ve managed to get a working updated solution for my services:

import { APIGatewayEvent, Callback, Context, Handler } from 'aws-lambda';

import { AppModule } from './app.module';
import { NestFactory } from '@nestjs/core';
import serverlessExpress from '@vendia/serverless-express';

let server: Handler;

async function bootstrap(): Promise<Handler> {
  const nestApp = await NestFactory.create(AppModule);
  await nestApp.init();
  const app = nestApp.getHttpAdapter().getInstance();
  return serverlessExpress({ app });
}

bootstrap().then((handler) => (server = handler));

function waitForServer(
  event: any,
  context: any,
  callback: Callback,
): Promise<any> {
  return new Promise((resolve) =>
    setImmediate(async () => {
      if (!server) {
        resolve(await waitForServer(event, context, callback));
      } else {
        resolve(server(event, context, callback));
      }
    }),
  );
}

export const handler: Handler = async (
  event: APIGatewayEvent,
  context: Context,
  callback: Callback,
): Promise<any> => {
  if (server) return server(event, context, callback);
  return await waitForServer(event, context, callback);
};

This seems to be working fine for me at the moment. But occasionally I’ll see an initial DB connection error in the logs on startup, although it always immediately retries and succeeds.

ERROR [TypeOrmModule] Unable to connect to the database. Retrying (1)...`

To be honest the error seems to have little impact, when it occurs. I’m guessing this occasional startup error could be caused by the container network services simply not being ready in time. 🤷