Documentation "highly recommends" an undocumented feature: serverless target

[SylvainGarrigues]

Bug report

Describe the bug

From the documentation:

server target

This is the default target, however, we highly recommend the serverless target.

It is explained that the serverless target will output autonomous modules, one per page, which export kind of wrappers around the http framework and therefore can be used in any cloud serverless function provider (e.g. Google Cloud Functions).

This does work indeed, but then the client code tries to fetch _next/data/{buildID}/{somepage}.json which the documentation doesn't mention.

Therefore, the documentation highly recommends an undocumented feature, which is confusing.

To Reproduce

1. Read the doc and contemplate how it is highly recommended to deploy with the serverless target and use the generated modules
2. Make use of the render method of (for instance) index.js from the build output in .next/serverless/pages/ in the code of a function of your favorite serverless function cloud provider (e.g. Google Cloud Functions)
3. Host .next/static in a _next/static folder so that example.com/static/ uses it, and have example.com/ be served by the cloud function
4. Repeat for other routes (for instance map /another to another cloud function which uses require('serverless/another.js').default.render
5. Open example.com in the browser and in the console watch the browser fail to fetch _next/data/{buildID}/another.json and force a full reload by redirecting to /another instead of using client-side routing navigation

Expected behavior

• Explain in the documentation what is needed to deploy the next.js framework in this highly recommended serverless configuration: access to disk for caching (and how to disable it in next.config.js), routes to be setup for _next/data and methods to be used (renderReqToHTML ?): not documenting this makes the serverless target kind of pointless while you highly recommend it in the same time
• Please do not merely point to non-official projets (e.g. serverless-next)

System information

N/A (applies to all systems)

[SylvainGarrigues]

Well, I am a bit disappointed this is solved by deleting the whole target documentation.

I guess the serverless target is still of interest, it was nicely introduced and promoted in the official Next.js blog, and still seems the way to go to deploy on cloud serverless functions like Amazon Lamba or Google Cloud Functions, and respectable projects like serverless-next may still be using it.

[timneutkens]

The general problem is that we've seen tons of people add target: 'serverless' to deployments that use next start thinking they get better performance while actually reducing performance by quite a bit as serverless wasn't meant for next start. We've also found over the years that the serverless target has quite a few problems and it was replaced by experimental-serverless-trace when deploying on Vercel for example. The only project that still uses the serverless is serverless-next and we're not planning to remove the target at this point. It'll be kept around for compat with projects like serverless-next. However, the documentation was only confusing to users and did not provide any value hence why it is removed. I wasn't aware we still had that section in the docs otherwise it would have been removed earlier.

Overall the TLDR is:

• The serverless target is not ideal as-is
• The serverless target is not going away for backwards-compat reasons
• The serverless target does not support most modern Next.js features like preview mode, revalidate, fallback

[SylvainGarrigues]

Thank you very much for sharing this, I understand.

In the future, if you can write (not necessarily in the official doc) about what is needed for non-monolithic deployment, I think that would be great, so that nextjs really remains deployment-platform agnostic (in serverless mode). Right now, following the documentation, either you go to Vercel or you have to find an always running nodejs server - therefore excluding the benefits of serverless deployments which are far more convenient (be it on Amazon or Google or Microsoft for instance).

Like I said in my original report, this would include how to use the per-page modules produced by the next build phase and the basic serverless functions needed (for _next/data, for image processing, etc). It doesn't need to be Amazon specific (like serverless-next), but enough to understand the global architecture nextjs client-side expects server-side.

[ryands17]

@timneutkens 👋
Is it possible to deploy on something like Lambda + CloudFront without the serverless target?

[PeterAronZentai]

@ryands17 - with the AWS Lambda Container Images feature you can now host an entire classic express/nodejs/next application in the lambda runtime - former size limitations wrt the deployment package are removed. You still will need to bridge (or translate) the Lambda event mechanics to be express compatible - I regularly use serverless-express.
However expect far less than optimal warmup times if you go down this path - as without the serverless option you do not get an optimal single file server side executable - (node modules will be resolved and loaded warmup time). Now if you apply sensible cache settings with CF - warmup times might not at all be a problem for you.

And just for sake of clarity AWS Lambda isnt (really) a supported origin target for CF, so you need a conduit: either API Gateway or Application Load Balancer between them.

[ryands17]

@PeterAronZentai Thanks for the reply! Based on this comment, would it be ideal to still use the serverless target or would it be better to serve Next.js via CF using Lambda@Edge using a custom server?

#20487 (comment)

[PeterAronZentai]

@ryands17 - I have actually built my suggested setup over the weekend - fullblown Next.js installation + convential Lambda + as Container Image, then I did a load test to see warmup times, and I am quite happy with the results. I am now putting together a repo plus some README to share how to do it.

As for running Next.js in LambdaEdge - I tried that with target:serverless a while back, worked ok, and while it was an interesting experience, I felt that it was a hack as well. LambdaEdge has severe limitations compared to just Lambdas (for example: you cannot use env, you cannot use container images, and you are tied to the us-east-1 region, etc). - I think LambdaEdge wasnt invented for running webservers.

My next is looking into Next.js 12's extra build outputs to see how those files could be utilised to get to a single file setup. Maybe a custom lambda host has some play in this.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.