Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build time for CircleCI #13

Closed
romainquellec opened this issue Mar 19, 2019 · 8 comments
Closed

Build time for CircleCI #13

romainquellec opened this issue Mar 19, 2019 · 8 comments

Comments

@romainquellec
Copy link

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 #11

@danielcondemarin
Copy link
Contributor

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 serverless/serverless#4263 can help.

@romainquellec
Copy link
Author

FYI, on CircleCI with 20 pages
image

@romainquellec
Copy link
Author

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.

@danielcondemarin
Copy link
Contributor

@romainquellec
Copy link
Author

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.

@danielcondemarin
Copy link
Contributor

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:

  • 250MB SSR pages (50MB zipped). Note that statically optimised pages (HTML) are not included here. Those are separately deployed to S3 so there can be as many as you want.
  • 250MB API pages (50MB zipped)

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.

@romainquellec
Copy link
Author

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 !

@danielcondemarin
Copy link
Contributor

Closing this. The new version of the project (component) doesn't use serverless package therefore is much faster building the app 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants