serverless 0.1.0

V0.1.0

on Node.js NPM

This is a major release and represents the finalization of our architecture. For months, we tested every architectural variation. The architecture in v0.1. represents the best possible approach for building AWS Lambda powered applications.

In this release there are several breaking changes. We apologize for this and we sincerely believe these are the last breaking changes. Fortunately, we make these changes to offer you a substantially better workflow, and the improvements in v0.1 will save you a lot of time in the long run.

To transition, we recommend creating a new project with Serverless v0.1.0 and moving your project assets to the new project. Any breaking changes listed below include notes on how to move your assets over to the new project:

• Breaking Change - Single Project Bucket: The framework now creates a single bucket on sls project create to hold all project data for all regions and stages, instead of creating a multiple buckets for each region your project uses. This has been a request for a long time and we've finally made it happen. The downside is existing projects will have to aggregate their regional buckets to the new single Project Bucket. By creating a new Serverless project, you will have the correct bucket naming convention -- serverless.<region>.<domain> -- but make sure you copy assets over to the new Bucket Key Structure, which is:

serverless/<projectName>/<stage>/lambdas // lambda back-ups
serverless/<projectName>/<stage>/<region>/<envVars> // ENV vars
serverless/<projectName>/<stage>/<region>/<resources> // CF Resources

• Project Variables: To reduce configuration settings across your project we now have Project Variables. You can use a Project Variable in any s-project.json, s-component.json, s-module.json and s-function.json file via this syntax: ${variable} Project Variables can be different for stages and their regions, which make them exceptionally powerful. In general, we recommend keeping all of your AWS account specific data in Project Variables.
• Breaking Change - _meta folder: This is a new folder in the root of your project which holds your Project Variables as well as copies of entire CloudFormation Templates that are produced as a result of aggregating all of the CloudFormation properties across your s-project.json and s-modules.json. The Serverless Framework keeps your project stages and regions data in here as well, in the form of folders. In each folder are s-variable.json files for storing stage and region specific Project Variables. By .gitignoring your _meta folder, you can share your project publicly!
• Breaking Change - Components: There is a new tier of organization in Serverless projects to help dependency management and allow for multiple runtimes within a single project, these are called Components. Components designate a runtime (e.g., node.js) and contain a single list of dependencies that is shared across multiple modules and functions (e.g., a single package.json). This allows your modules and functions to all use one set of dependencies, which greatly reduces dependency management and maintenance. Components sit between your project and groups of modules. You can think of Components as microservices. A common pattern is to have 1 component containing modules and functions for a REST API, and another component for modules and functions that respond to events on your AWS account. This could look like this:

project/restAPI-component-nodejs/modules/functions
project/eventHandlers-component-python/modules/functions // Python support is almost finished!

• Breaking Change - Plugin Package.json in Project root: Every Serverless project now expects a package.json in the root of your project, which contains plugin dependencies. This was previously located in project/plugins/package.json, but now is at project/package.json. This was a heavily demanded feature and we hope it makes everyone's workflows much better.
• Breaking Change - Resource Management: There is no longer a resources-cf.json file containing your Serverless Project's resources. Instead, you modify resources in the cloudformation properties of s-project.json and s-modules.json. When you run serverless resources deploy, Serverless aggregates CF resources from your modules and project, then prints a s-resources.json file in your _meta/resources and updates CloudFormation based on that file. You can use serverless resources deploy -c to not trigger the CloudFormation update and only print the s-resources.json file.
• Templates: To further reduce configuration settings in s-module.json and s-function.json we now offer reusable templates. Templates can be any data type (e.g., objects). They are defined in s-templates.json located at the root of your modules: project/component1/module1/s-templates.json. To use a template that is located within a module, use similar syntax to our new Project Variables: $${moduleName.template}. By including the moduleName you can use templates located in other modules. We've almost completed templates at the project level project/s-templates.json which you will specify without the module name, like $${templateName}, but we didn't quite finish it before releasing. If anyone wants to help finish this feature, that would be greatly appreciated :)
• Stage Create & Region Create: When these are created, your CloudFormation resources are no longer deployed by default. You must run serverless resources deploy for those new stages/regions.
• Dash Deploy Must Be Used Within Modules: The Serverless CLI Deployment Dashboard does not work well with long lists of Lambda functions, so you currently can only run it from within a module folder.
• Temporary Removal Of Module Install: We've temporarily removed the module install command so that it will work with our new shareable module design. This will be back shortly.
• Breaking Change - Deployed Function Names Now Include Component Name: To avoid conflicts across deployed lambda functions in multiple project components, deployed lambda names now include the component which they reside within, in your project.
• Breaking Change For Plugins - Introducing Serverless Classes: To provide a better experience for plugin developers, we have stopped attaching large objects to the evt objects that are passed to every Action and Hook. Instead, we now pass only Serverless Paths to identify modules/functions/endpoints the Action should work with. Most importantly, we now have great new classes for Plugin Developers to use when making plugins. We have classes for Serverless Project, Component, Module, Function, Endpoint and more! Each class is full of useful methods which Plugin Developers can use to build faster. Even better, there is a new Serverless State class. This is instantiated each time an Action is run via the CLI or when calling serverless.init() programatically. This State class contains the most methods for Plugin development. These new Classes and their methods represent a stabler API for Plugin developers to rely on, and they are super powerful. Please read more about them in our documentation.