NextJS 12 results in less standalone setup for serverless environments than NextJS 11

[fast-reflexes]

Run next info (available from version 12.0.8 and up)

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 19.6.0: Thu May  6 00:48:39 PDT 2021; root:xnu-6153.141.33~1/RELEASE_X86_64
Binaries:
  Node: 14.17.5
  npm: 6.14.14
  Yarn: N/A
  pnpm: N/A
Relevant packages:
  next: 12.0.8
  react: 17.0.2
  react-dom: 17.0.2

What version of Next.js are you using?

12.0.8

What version of Node.js are you using?

14.17.5

What browser are you using?

Chrome

What operating system are you using?

MacOS

How are you deploying your application?

Other platform

Describe the Bug

Version 11

NextJS 11 had the serverless target which, despite some more dependencies than advertised, was an attempt at making serverless functions from each dynamic page. The idea was that the serverless page could be deployed like a render function only without any resources. This was in fact almost right, even though some dependencies actually existed, which was reported here: #26297. Nonetheless, despite these extra resources, you could actually copy the render function along with about five or so dependency chunks and it all worked; you didn't even have to run a server to render the response.

Note well that NextJS adds some middleware to both API requests and API responses:

• https://nextjs.org/docs/api-routes/api-middlewares
• https://nextjs.org/docs/api-routes/response-helpers

An arbitrary API page written for NextJS will assume that these exist. In NextJS version 11, one of the dependency chunks that I talked about, that resides inside the .next/serverless/pages/chunks folder, enhances the req and res objects with this in function apiResolver.

To sum up, in version 11, all you needed was the following file system to serve a given page:

.next
    serverless
        chunks
             ... (about 5 chunks)
        pages                 
            api
                ... (api pages)
            ... (regular pages)
index.js (some file that reads an incoming message and then calls resources in `.next`)

Version 12

Version 12 has ditched the serverless target at the benefit of outputting a file for each page containing information about the dependencies. This way we will clearly see the needed dependencies and may copy them to the location where they're needed. There is also the option to let NextJS do this for us, whereby a standalone folder with node_modules and the whole shebang is included. The problem now, no matter if we use the standalone option or not, the apiResolver method where the extra middleware is added has been moved to node_modules/next/server/api-utils.js which means we MUST include node_modules folder to get the expected NextJS equipped req and res objects in our standalone pages. It also seems that the apiResolver method, which was in version 11 called from the standalone api function itself, is now called from the base-server in the server package, indicating that we need to start a server to ornament the req and res objects with the necessary api middleware / helpers.

Conundrum

It seems to me that from a general serverless perspective, NextJS just took a step backwards and we are with version 12 required to both keep a node_modules folder and also start a Node / Next server to be able to properly handle api requests whereas we could do the same in version 11 without both. Starting a server is more time consuming than just rendering the response from a function and keeping the node_modules folder around takes up more space than necessary as well. Perhaps given some specific serverless platform, this is a step in the right direction but if so, then it is a shame that it should be at the cost of a general usability in serverless contexts.

Please enlighten me if I have misunderstood something or if I'm wrong in any way, I would be really glad if I am :)

Expected Behavior

Improved architecture from version 11, perhaps with the rendering functions actually being standalone as advertised instead of depending on the .next/serverless/chunks folder.

To Reproduce

1. Start a new Next project with npx create-next-app

2. Run next build

3. Copy the contents of .next folder to a new folder serverless

4. Verify the dependencies for default api hello endpoint in .next/server/pages/api/hello.js.nft.json to be only the main package.json and .next/server/webpack-api-runtime.js

5. Delete all files in the serverless folder except .next/server/webpack-api-runtime.js and .next/server/pages/api/hello.js

6. At the root, create a serverless entrypoint index.js with content

    const renderer = require("./serverless/server/pages/api/hello")
    const http = require("http")
   
    const run = () => {
        const req = new http.IncomingMessage(null)
        const res = new http.ServerResponse(req)
        return renderer.default(req, res)
    }
   
    run()
   

7. Run node index.js

8. Verify error res.status is not a function

The default api endpoint makes use of NextJS specific res.status() ad res.json() which doesn't work since the req and res objects have not been ornamented with these extra capabilities through the apiResolver function.

Adding

module.exports = {
    experimental: {
        outputStandalone: true,
    }
}

to next.config.js and using the entire .next/standalone in place of the above serverless folder does not change the results, indicating that we must indeed spawn a server (perhaps the included server.js) to get the embellished req and res objects that are expected, which in turn also suggests that we need to keep a node_modules folder around.

[hughesjj]

Hey, please let me know if you make any progress on this. The serverless team is working on getting their plugin supporting next 12, and they have some partial progress in place. I'm looking to see what they do and hacking it into my own app.

serverless-nextjs/serverless-next.js@e01571f#diff-2eca37e76392da91d76c7cb54a9d2704e3b6aeda484b6ddd8b8e0bdf089ebddb

[iiroj]

Hello, I just want to let you know I'm not part of the serverless team myself, just rely on it in my dayjob... The PR I had turned out to not be sufficient, and requires integrating a totally new lambda handler spawning the Next.js BaseServer.

My progress is here:
https://github.com/s-group-dev/serverless-next.js/tree/output-standalone

I figured it would make more sense to use the experimental.outputStandalone setting and just have the build process copy the entire .next/standalone. This isn't working just yet, because it seems even with standalone there are some missing Next.js files.

[fast-reflexes]

Thanks for chiming in! I wrote a lambda handler 6 months ago that gives the user the option to:

• Run renderer function manually (no server, no node_modules)
• Run renderer function by starting a Node server (server, no node_modules)
• Run a NextJS server (server, node_modules)
• Run a Node server with a NextJS handler (server, node_modules)

It's currently only using NextJS as target framework but it's built in a modular fashion so it's easy to add other frameworks as well.

Obviously, the 2 last render strategies take more time (like 1-2 orders of magnitude) and requires a lot more space due to node_modules folder. The last two strategies still work with NextJS 12, but as I wrote above, it's a step in the wrong direction. It's not that it's infeasible to start a server and render the response from it but it's kind inefficient when it could OBVIOUSLY be done in a better way with NextJS 11.

I just started this thread to see if anyone from the NextJS team could inform us users about what they were thinking; either there is some huge misunderstanding and it can be done in a simpler way than outlined above, or it would be interesting to see what they had in mind.

Also, it doesn't matter if we use experimental.standalone or not, we seem to still be forced to wind up a server and send an artificial request to it, experimental.standalone just takes care of some file organization for us.

It's just kind of absurd isn't it... given a cloud provider we now have:

1. HTTP request to Cloud provider
2. Lambda event from cloud provider to lambda
3. Start up server in Lambda
4. Convert lambda event BACK into HTTP request
5. Await HTTP response from temporary server
6. Convert HTTP response to lambda response event
7. Cloud provider turns lambda response in HTTP response

It's not an architectural dream if I may say so and with NextJS 11, step 3-6 at least did not have to involve starting a server and converting the lambda event into a full-fledged HTTP request (even though converting it into an IncomingMessage is perhaps not so much simpler after all).

[fast-reflexes]

I'm currently not working on it, sticking with NextJS 11 ... I mean, if you're ok with storing a node_modules folder in your lambda and firing up a temporary Node server, NextJS 12 works fine for serverless but that's such a suboptimal pattern compared to how it can be done in NextJS 11 with just a render function and an IncomingMessage and ServerResponse (no node_modules no temporary server). I'm just curious what the development team had in mind for this functionality.

Anyways, I don't see where a page is actually rendered anywhere in the commit you pointed to, I guess that's the interesting part... whether that can be solved in a non-hacky way without all these extra stuff or not.

Will post in this thread if I find something interesting :)

[hughesjj]

To my understanding it's not rendered there, but that's the logic there were implementing for the .nft.json files and similar to include. I believe the existing rendering code works from v11, it was just a matter of including the output paths from the new format.

Thanks for your response, I'm reaching a similar conclusion. Honestly I'm debating just dropping nextjs altogether....

[jinqian1998]

I really agree with you @fast-reflexes .
I saw Tim raised up a PR about removing target in next config, it still in progress but it surely will be removed...
#34476
For now, I tried a lot ways deploying nextJS 12 to lambda, but all failed... Some opensource library like "https://github.com/serverless-nextjs/serverless-next.js" also using target: serverless under the hood.
I noticed some Cloud company like Tencent Cloud just deploy a http server and proxy the requests...
Like you said, run a http server every time is kind of stupid, But for now, I have no better way.

Thanks for your discussion!

[markbdaniels]

Hi @fast-reflexes / all,

Any chance you found a solution. I spent a lot of time this weekend trying to get Nextjs 12 running in a Lambda...
I also do not want to use the serverless plugin.

I might give in and run a web server within a lambda and if so I found this - https://github.com/aws-samples/aws-lambda-adapter/blob/main/README.md. Any other suggestions on how to do this?

[jinqian1998]

Hello @markbdaniels , seems the "aws-lambda-adapter" is just a lambda layer, and we could use it to convert the event to http request. You can see inner the lambda docker image, this adapter is work as a "wrapper":

According to the demo, we could just run the nextJS inner lambda, and add the adapter as a layer.
I haven't tried it yet. Waiting for your good news XD

[markbdaniels]

Haha, hopefully I have some good news in next few days. Will give it a shot.

I'm not too familiar with layers etc and just concerned about pulling in some random layer without knowing what's being executed but will do a bit more research.

[Naveed-Iftikhar]

goodd

[jinqian1998]

OHHHHHHHH, what good news?

[fast-reflexes]

The problem is not that we can't run NextJS 12 in a Lambda, the problem is that NextJS 12 makes it more cumbersome and less Lambda friendly.

I have a NextJS lambda handler that I wrote some time ago and in that project, I tried to explore all the ways you could generate a NextJS response from a Lambda event. The following were the methods I tried in that project:

• Generating a response right from the method handler (e.g. converting the incoming Lambda event to an IncomingMessage and call the handler with the resulting IncomingMessage and a ServerResponse object. In NextJS 11 this requires ONLY the handler method and a chunks folder with some extra files. Back in the days, I thought it was wrong that these chunks files were needed since NextJS docs claimed that ONLY the generated handler file / lambda would be needed. I filed a complaint about this here.
• Running a basic Node server which calls the handler method and returns the response. This requires converting the Lambda event to a RequestOptions object instead which in turn can be used to create a ClientRequest from the http.request method in Node. This method is quite good as well since only the same files that we needed in the last strategy are necessary.
• Running a NextJS server (like we do when we have built a project and then run our project locally with npm run start). This is much less efficient since we now need node_modules with a nextjs installation and so on. This method also requires us to transform the Lambda event to a RequestOptions object.
• Finally, we may also run a standalone server with a NextJS request handler (like we do when we want to use a custom server in NextJS). This method is essentially no different than the above since we still need node_modules with a nextjs installation for the request handler.

So, what NextJS 12 essentially does is that it removes the possibility to use either of the first two methods and now we BOTH have to start a server AND have a nextjs installation in node_modules. Nonetheless, it is still doable;

• Convert Lambda event to RequestOptions object and body string.
• Start a NextJS server.
• Run a http.request with the RequestOptions from first step, a possible request body and a callback function against your local NextJS server (updating some values in the request as necessary for the request to work out).
• Handle the response in the callback function and then closing your local server.
• Convert the response to an output Lambda event.

Sounds straightforward, and even though it's doable, there are a lot of small things that can go wrong :)

Seems the previous posts are about using some outside layer to turn the Lambda event into a ClientRequest? If so you could do it yourself as well if you spend some time on it but it seems good if there is an existing solution for it.. nonetheless, I only reach 404 when I click the link :D

[jinqian1998]

@fast-reflexes Thanks for your effort!

[svedova]

Hi everyone 👋

I see that the target: serverless option is being deprecated.

What's the suggested way to bundle for serverless? For previous versions, on Stormkit we are checking for a serverless subfolder in the .next folder and if it's present we are adding a simple wrapper which calls spawns a local next serverless instance and it handles the routing itself.

For newer versions however, I see that providing the target: serverless option still produces a serverless subfolder but since it's going to be deprecated, how can we tell Next to build for serverless?

[svedova]

This is super cool - thank you! I'll look further into it 🙏🏻 It looks like it's main use case is packaging an app for lambda though. We somehow need to tell Next.js to build for serverless without specifying the serverless target option.

[iiroj]

I don't think Next.js will support a "serverless" mode going forward... with target being deprecated and the outputStandalone option basically emitting a server.js, I believe a Lambda handler will just have to create a server and a request handler for every request.

[svedova]

@iiroj thanks for the answer! So I suppose all we have to do is to transform the AWS lambda event into a Node.js HttpIncomingMessage and pass it to the server.js file. The routing will be handled by the server.js file I suppose?

[iiroj]

The emitted file opens a long-lived server, but the code is so simple that it can be recreated. Take a look at this, for example:

https://github.com/s-group-dev/serverless-next.js/blob/76f9b532b262c30bd981425650293d462c2ba3f8/packages/libs/lambda-at-edge/src/next-handler.ts

[svedova]

Awesome, thanks a lot super helpful @iiroj 🙏

[rohanshiva]

@jinqian1998 any update on using https://github.com/aws-samples/aws-lambda-adapter

[iiroj]

For what it's worth, I succesfully used the AWS CDK to deploy a Next.js application to Cloudfront, Lambda@Edge and S3. It uses the new output: 'standalone' option of Next.js: iiroj/iiro.fi@bd43222

[bnusunny]

Hello, I created an example to show how to deploy a simple Next.js application on AWS Lambda with Lambda Web Adapter. You can find the code here: https://github.com/awslabs/aws-lambda-web-adapter/tree/main/examples/nextjs

Thanks @rohanshiva for raising awslabs/aws-lambda-web-adapter#58 in Lambda Web Adapter repo.

[Alynva]

This creates one lambda for all pages, right? There isn't a way to have multiple lambda, for each page/api in the app?

[bnusunny]

Yes. This is one Lambda function for all pages.

[bnusunny]

Thanks to @julianbonilla, we have an example to host Next.js 12 application on Lambda with Zip packaging format. It has faster cold start time. Check it out here: https://github.com/awslabs/aws-lambda-web-adapter/tree/main/examples/nextjs-zip

[sladg]

Hey all!
After few weeks of experimenting, I made it work :) here is a package to make Next12 work on Lambda without using Edge.
https://github.com/sladg/nextjs-lambda

[martg0]

@sladg thanks for the info! regarding website performance compared to edge, do you have any insights to share?

[sladg]

@martg0 I don't have enough data to make reasonable statement on this, however, Cloudfront is doing good job in terms of caching client pages. API routes are for sure a bit slower, but we are talking ~50-200ms. I have region specific apps, so cannot comment on situation when app is used across all continents.

Overall, no-one noticed the switch from Edge to normal Lambdas for my usecases.