https://serverless-stack.com/ logo
Join Slack
Powered by
Any tips on making the build process faster? Our ...
# sst
d
Any tips on making the build process faster? Our build process has grown very slow. We’re considering moving our node_modules into a lambda layer. We haven’t looked very closely at what is bundled into our lambdas yet. Any documentation on where to start?
a
I have not moved dependencies to a lambda layer because what that would slow down cold starts, as you loose the benefits of bundling all code together and tree-shaking. It will speeds up builds (you can just disable tree-shaking to do that), but at a runtime cost. It's also more to maintain. Many lambdas make for slower builds. Unfortunately SST rebuilds all code every time, even if nothing has changed. That's probably unavoidable for full deployments. There's an opportunity to optimize only building Lambdas in a stack, if you use the option to only deploy one stack.
t
we have some work coming up to work around CDK's synchronous building to run builds more in parallel
that also opens the door to only building changed lambdas
for speeding up builds today though the work does involve analyzing your bundles and seeing if they make sense or if you're bundling things that don't need to be bundled
the answer there is usually yes because bundling efficiently requires a few intentional patterns
a
Maybe @Drew try disabling tree-shaking in esbuild for development environments, but leave it on for CI/CD? 🤔
The saved processing time saved may be reversed by larger code bundles uploaded.
d
@Adam Fanello we’ll try that! 🤞
Looking forward to eventually seeing all the new performance tweaks @thdxr ✨
I wonder if I could put our shared code into a node_module, instead of a lambda layer. We could treeshake that module once, instead of for each lambda
t
is each individual function build slow? or is that you have a lot of funcs
a
Tree shaking should happen regardless of where the code is in the directory structure.
d
We do have a lot of funcs, and they build slow 🤷
Adam, I’m assuming that if it already has been shaken, then it’s faster to shake again
t
I would first try and see how long a single function takes and what the bundle size looks like
Copy code
esbuild --bundle  --platform=node ./path-to-func --outfile=output.js --analyze=verbose
esbuild is very fast unless you have giant bundles (which is bad for lambda as well) so I think your issue is less around a single func being slow and more than you have a large number of funcs and doing them one by one gets linearly slower
d
✨ super, that makes sense.
t
and that's why we want to introduce parallel builds because esbuild's api supports that really well, it's just CDK's design that's flawed
d
Our functions are all identical, and we may just have giant bundles
t
oh if they're identical then can you just create it once and pass around the function?
or do they have different env config?
d
We have ~133 functions that share 90% of their code with each other
Oh ya, many of our functions could probably use a shared one that’s created once, and passed around.
t
so during builds we do initialize esbuild once and then reuse it for every function build so theoretically it should benefit from 90% of the code being shared but if the bundle is large it still need to write it to disk
d
Awesome, thanks @thdxr
It only seems to take 2 seconds to build a function.
t
133 * 2 adds up
yeah I'll try to get you in the beta for when I implement parallel builds, really curious how your stuff will be sped up
d
Yep! Really looking forward to your work there
Thanks for the 
sst bundle --analyze
idea @thdxr — we’ve discovered we’re bundling at least 1 massive package into each lambda fn
f
Just to chime in, @Drew 2s seems really slow, usually double digit ms on my old macbook.
Do you have 
bundle
set in default function props any where?
d
Nope, I don’t think that I do — should I?
I’m also bundling extra files into the lambda archive. I have a /src/api/handler.js for my handler, but I also have a /src/db/ folder full of SQL files that I don’t want. Any tips on how to filter these out? @thdxr @Frank
t
is src/db full of js files?
d
Nope, sql files
t
it should only be included if you have 
copyFiles
specified somewhere
d
Ah, I’ll hunt for that
We do have 1 or 2 lambdas that use these files
I’d rather purposefully include them when needed, rather than including them in every lambda
Found it! Thanks
Open in Slack
PreviousNext
Powered by