Experience using Serverless 1.0 with CircleCI

Deployments
1

Posting our findings when using Serverless 1.0.0 beta 2 with CircleCI.

We’re building a number of services for AWS API Gateway/Lambda service and obviously wanted to deploy from Circle. Since we already had some Serverless 0.5.x projects, we didn’t want to install Serverless 1.0 globally, so decided to include it as a dev dependency in each individual project. Once we’ve migrated everything to sls 1.0 we’ll most likely remove the dependency.

This worked fine locally where we could run sls deploy --stage dev with no problems. Once we tried to define a deployment into our circleCI config we found that the deployment was hanging 95% of the time, but often at different points in the deployment process and every now and then it would work.

With some help from the guys at Circle we determined that the zip file created by serverless to deploy to S3 was huge and causing our build instance to run out of memory. From this we realised that the default serverless deploy includes the whole node_modules directory in its zip file and doesn’t exclude dev dependencies.

To deal with this, we’re using the serverless-webpack plugin that allows us to reduce the size of the zip file to include only the dependencies needed for our lambda function. We got the added bonus of being able to transpile with babel as part of the typical webpack process.

Note that some node modules don’t like being parsed by babel or included by webpack (eg pusher). To avoid problems here, we define all node_modules as external to webpack, and then include the required runtime dependencies explicitly in the plugin config in serverless.yml

Hope this help others avoid wasting time on build/deploy problems.

3 Likes
2

Hey thanks for sharing!

Right now we are going through the exact same process.

I assume you are using the serverless-webpack 1.0.0 beta 2.2 to have the options to include the dependency while declaring them as external.

But I don’t know if we should define all node_modules as external or not. Right now I am only using it to include some source-map-support. What is the benefit declaring them as external compared to bundling them all together?

Thank you for your insight!

3

Thanks for sharing this.

4

@TaichiHo: check out James Long’s blog post on the use of webpack for backend apps : http://jlongster.com/Backend-Apps-with-Webpack--Part-I

We’ve pretty much done the same thing in our webpack.config.js, however his post assumes that the depencies are already available on the server. But when used in conjunction with serverless-webpack, this means that the webpack bundle is minimal and you need to explicitly define the runtime node module inclusions in your serverless.yml to have them included in the deployed zip file.

Ultimately I’d prefer it to just look at my package.json and include the runtime dependencies defined there so I only maintain one list of runtime dependencies.

5

Hi have there been any advances (even planned) for RC1?