Questions - Developer Experience with this plugin

[Vadorequest]

I have a few questions regarding the stability and production-ready usage of this plugin. I'm concerned overall about the Developer eXperience, basically the ability to debug, develop locally, how does the local env matches the production env, but also about performances and cold starts.

I've been using Next since v5, and I'm currently running v5 in production, powered by Express, which powers Next.js. I've handled cold start by using AWS Heath Checks and calling a dedicated route to warm the whole thing. Cold start take around 3-6sec, depending on the allocated RAM.

The new "serverless" approach is fundamentally different, as each page lives in its own lambda, and therefore warming all the endpoints gets complicated. But maybe it's not needed anymore because each page may render much faster than my 3-6 sec using v5. (I know Next.js has had multiple performances improvements since v5, but don't know much about it)

With my current app, I also have endpoints that aren't next-related and are handled by Express (basically, an API). I guess the new correct approach would be to have a dedicated lambda to handle those. I see two approaches:

1. I could either have an /api endpoint powering and express server as I did before (but not related to next this time, as it'd live in another lambda)
2. I could also use one lambda per API endpoint, but don't quite see the benefits of doing that

Also, I'm wondering how does HMR work when working locally. My current Next 5 setup is tricky. I basically have the serverless-offline that lives on :3000, without HMR. And I have the Next app that lives on :3001, with HMR. I basically dev on 3000/3001 based on whether I do front-end or back-end stuff, but that's far from being perfect and I'm really looking forward to improve that.

I guess those points are my main concerns about switching/upgrading. I'd appreciate any feedback regarding those :)

And, thanks for this plugin, that's a really great idea @danielcondemarin ! I believe it'll help bring Next to another level, because let's be honest: AWS Lambda is so cost-effective and Next is such a great React framework, it really makes sens to put those two together using Serverless and it's a wonderful way to have a ready-to-deploy app in a matter of minutes.

[danielcondemarin]

Those are all really good points / concerns. Hopefully I can address them below:

I'm concerned overall about the Developer eXperience, basically the ability to debug, develop locally, how does the local env matches the production env

Currently the best developer experience would be to just use next dev. However, this doesn't work if your app setup goes outside the defaults, for example, if you have custom page routes in the api gateway, custom authorisers etc. That would only be supported locally by serverless-offline. This plugin is compatible with serverless-offline, however, HMR doesn't work with it as of the current implementation.
In an ideal world, we'd use serverless-offline with HMR support. That way any API GW or Lambda local support comes for free, or even if you have other APIs in the same serverless.yml etc. The now platform very recently introduced now dev which supports serverless pages locally. For that to work I think nextjs added serverless dev page bundles, which this plugin should be able to use.

I'm currently finishing the work on the static assets routing and I intend to look at this next. It would be super helpful if there are any takers on starting some investigation on what would be involved to get this working.

The new "serverless" approach is fundamentally different, as each page lives in its own lambda, and therefore warming all the endpoints gets complicated. But maybe it's not needed anymore because each page may render much faster than my 3-6 sec using v5

Each page living on a separate lambda will be less code initialisation and memory footprint which certainly improves cold starts. In terms of the warmup, you're right it would be more difficult to do the same when pages are distributed like this.

With my current app, I also have endpoints that aren't next-related and are handled by Express (basically, an API). I guess the new correct approach would be to have a dedicated lambda to handle those. I see two approaches:

I could either have an /api endpoint powering and express server as I did before (but not related to next this time, as it'd live in another lambda)
I could also use one lambda per API endpoint, but don't quite see the benefits of doing that

You're right, both approaches are fine and have their own pros / cons. This is an excellent post on the subject.

As it stands, this plugin is a build and deployment tool which tries to honor next's opinionated defaults on a serverless environment using API GW. You're quite right the developer experience is far from ideal, but I hope that can be solved in a not so distant future :-)

[Vadorequest]

Thank you very much for the fast & detailed feedback.

It's hard to get HMR working with serverless-offline, I know because I've tried with Next5, and failed. I wouldn't know where to start though. I remember I had tried to ignore the _hmr routes and re-route them to be handled by Next.js, but that was a blind attempt at fixing something I didn't know how the internals.

About warmup, it's not critical if it warms fast, so that's the real question at hand, how fast does a cold start need to render the page? Would be interesting to have some stats about that, because if Next has improved their bootstraping time then it may be completely useless to warm anything.

Thanks for the article. I tend to prefer not to have distinct functions, because it's easier to manage them as a whole, using Express for instance, but yet keep the logic separated because in the end Express is mostly used as a router which route the right call to the right function. It helps with reusability, allow to use middleware and makes it easier to share common logic, such as input validation (joy, etc.) - But that's my current state of mind, which isn't any kind of truth, and may evolve with time

[danielcondemarin]

A good starting point with HMR would be to check how now dev implements it and hopefully use some ideas from there.
I agree that warmups might not be necessary, not seen any benchmarks of next 8 serverless on a Lambda but should be easy to measure. This benchmark talks about 13.94ms avg cold time for React ssr which sounds great. Obvs this doesn't measure the overhead added by next.

[Xiphe]

I managed to get serverless-offline support by starting a next server on a seperate port and proxy all requests to it. HMR works by redirecting the requests directly to the next server.

Feels quite hacky though ;) And it does not take custom pageConfig into account as @danielcondemarin pointed out.

[danielcondemarin]

Hi folks the direction I'm taking here is to use next dev for local development, that is, no need for serverless offline and just leverage what next provides out of the box. I have just released a new iteration of the project which follows this philosophy and should supersede the next plugin. https://github.com/danielcondemarin/serverless-next.js/tree/master/packages/serverless-nextjs-component. Please check it out and let me know what you think 🙏