Support AWS Lambda as target serverless

Hey 👋

Thank you a lot @timneutkens for great #5927 PR, amazing work 🥇

I was going through the code of your PR in order to make it work with AWS Lambda and it was pretty straightforward.

I had to “hack” your next-serverless-loader.ts function in order to be able to inject serverless-http module that way:

// next.config.js

const nextServerlessLoader = require("next/dist/build/webpack/loaders/next-serverless-loader");
const { stripIndent } = require("common-tags");

const originalLoader = Object.assign(
  {},
  { default: nextServerlessLoader.default }
);
nextServerlessLoader.default = function() {
  const transformed = originalLoader.default
    .call(this)
    .replace(`export async function render`, `async function nextRender`);


  const result = stripIndent`
    import serverlessHttp from 'serverless-http';${transformed}
    export const render = serverlessHttp(nextRender);
  `;

  return result;
};

module.exports = {
  target: "serverless"
}

This is working great, the output can be directly plugged to an handler 🏆

functions:
  index:
    handler: .next/serverless/pages/index.render
    events:
      - http: GET /

Here are my questions:

• Are you willing to support other platforms than now.sh?
• If yes could we expose an option to auto-import the serverless-http module?
• If not, should I write a custom plugin to nextjs?

Cheers ✌️

[Vadorequest]

I’ve been working with Next on AWS Lambda for more than a year, and the lack of official example/support is painful indeed.

It’s really not easy to properly setup next on AWS, and it’s even harder to have a local/dev env that properly simulates AWS Lambda.

Also, AWS Lambda is -by far- the most used (compared to GCP, Azure, and others), and it would really make sense for the Next.js community to target this system, as it is one of the cheapest yet most reliable out there. Also, it fits particularly well with the Next 8+ “serverless” approach, but needs guidance to do it right.

The most advanced way I’ve seen so far is https://github.com/danielcondemarin/serverless-nextjs-plugin. I had made my own AWS Lambda + Next 5 + Express back then https://github.com/Vadorequest/serverless-with-next and I’m still running this in production (and looking for an up-to-date replacement, having a hard time to upgrade myself, see https://github.com/zeit/next.js/issues/7823)

There have been numerous open source attempts to make AWS Lambda work with Next over the past year, I can’t count how many work-in-progress repositories I’ve come across, such as https://github.com/justinwhall/nextjs-serverless-aws

The recent Next 9 update brings a lot of much welcomed capabilities/possibilities that are currently in discussion, see https://github.com/danielcondemarin/serverless-nextjs-plugin/issues/101 and https://github.com/danielcondemarin/serverless-nextjs-plugin/issues/105.

So far, I’ve seen two very different ways to go “serverless” with Next:

1. The “express” way, by having one big AWS Lambda that handles all incoming requests, and then split them between Next or something else. That’s what I used in https://github.com/Vadorequest/serverless-with-next and this approach allowed me to have a local env very similar to AWS Lambda. But it’s much heavier and cold starts are expensive (~5sec), but also much easier to warmup since there is only one endpoint to warm it all.
2. The “serverless” way, recently introduced by Next 8 and its “serverless” mode, where each page is a different lambda, loading only what’s necessary, keeping all endpoints very lightweight and reducing cold starts. It’s also what’s used by https://github.com/danielcondemarin/serverless-nextjs-plugin

Honestly, I don’t know what’s the best approach here. Both have their pros/cons. I like the express way, because it makes it so much easier to use middlewares and it’s a huge time saver. I haven’t seen anything similar to middlewares using the “serverless” way so far. It’s much heavier, but also easier to warmup. And I don’t know how much faster does the “serverless” way is for cold starts. Are they really so insignificant that we can ignore them? Not quite sure about that. What I know is that if we need to warmup in “serverless” mode, it’ll be much more difficult/expensive to do so.

Also, I don’t know how many existing apps are out there using the “express” way, and it’s gonna be hard to migrate apps from “express” to “serverless”, as we must find a proper replacement for all middlewares, and other things.

So, the point of all this talking is to clarify that there are -at least- 2 ways to use Next.js on AWS, and it hasn’t been proved yet that one way is “better” than the other. Also, there is a lot of efforts made by the community to make Next and AWS Lambda play together, but very few successful ones due to the complexity around those.

It’d very much be a game changer if the Next.js core team would tackle this issue and provide a reliable way of making Next working on AWS Lambda.

[danielcondemarin]

Hi 👋 I’ve been working on a plugin (https://github.com/danielcondemarin/serverless-nextjs-plugin) for the serverless framework that targets nextjs 8 serverless mode. It adds the compat layer between the AWS Lambdas and the Nextjs page handlers at build time and takes care of uploading the static assets to S3. Seems promising so far, but is still a WIP and haven’t been able to test it in anger. Is this something the folks in this thread using the serverless framework would be interested at? Would be good to get some feedback.