I'm using Circle CI for deploying my site.
Right now, "serverless package" is very long compared to "next build".
With config.optimization.minimize = false on next.config.js (to minimize next part)
Next build : Done in 37.92s.
serverless package : Done in 761.15s.
Its maybe related to https://github.com/danielcondemarin/serverless-nextjs-plugin/issues/11
Not sure I can do much about this tbh.
I'm seeing:
107 seconds - next build
188 seconds - serverless package
Macbook Pro
Intel Core i7 2.2GHz
Memory: 16GB
Maybe some of the suggestions here https://github.com/serverless/serverless/issues/4263 can help.
FYI, on CircleCI with 20 pages

One way to fix that is to decompose "sls package" into different steps (mainly, next build and createHandlers).
This way, all CI's won't break.
@romainquellec I believe https://github.com/danielcondemarin/serverless-next.js/tree/master/packages/serverless-nextjs-component can help here. Deployments should be considerably faster.
Thanks ! I will try the new version soon.
(Not related to the issue, but i'm a bit scared by this decision : "One master lambda is provisioned". I will dig that later also :D)
Thanks again for all this. This is awesome.
Thanks @romainquellec !
Regarding your concern, I've given a lot of thought to the architecture of the component. It is more flexible than it might seem. Right now is one lambda (which is replicated across the globe),. However I am currently working on splitting off the API pages onto a separate Lambda. pages/api/* will be deployed in its own Lambda@Edge.
That way you get:
That should cover most apps out there. However, if it needs be, you could still scale horizontally the architecture by adding more cache behaviours (like api/*) but I don't think that's necessary right now.
Getting rid of API Gateway provided massive wins in reducing complexity and latency. I will be documenting a lot more about this design decisions in the upcoming days.
I fully trust you and your work !
I will be documenting a lot more about this design decisions in the upcoming days.
Waiting for this. Thanks !
Closing this. The new version of the project (component) doesn't use serverless package therefore is much faster building the app 馃殌
Most helpful comment
Thanks @romainquellec !
Regarding your concern, I've given a lot of thought to the architecture of the component. It is more flexible than it might seem. Right now is one lambda (which is replicated across the globe),. However I am currently working on splitting off the API pages onto a separate Lambda.
pages/api/*will be deployed in its own Lambda@Edge.That way you get:
That should cover most apps out there. However, if it needs be, you could still scale horizontally the architecture by adding more cache behaviours (like
api/*) but I don't think that's necessary right now.Getting rid of API Gateway provided massive wins in reducing complexity and latency. I will be documenting a lot more about this design decisions in the upcoming days.