service is like a project. It's where you define your Azure Functions, the
events that trigger them and any
resources they require, all in a file
To get started building your first Serverless Framework project, create a
In the beginning of an application, many people use a single Service to define all of the Functions, Events and Resources for that project. This is what we recommend in the beginning.
myService/ serverless.yml # Contains all functions and infrastructure resources
However, as your application grows, you can break it out into multiple services. A lot of people organize their services by workflows or data models, and group the functions related to those workflows and data models together in the service.
users/ serverless.yml # Contains 4 functions that do Users CRUD operations and the Users database posts/ serverless.yml # Contains 4 functions that do Posts CRUD operations and the Posts database comments/ serverless.yml # Contains 4 functions that do Comments CRUD operations and the Comments database
This makes sense since related functions usually use common infrastructure resources, and you want to keep those functions and resources together as a single unit of deployment, for better organization and separation of concerns.
To get started, you can simply use the
create command to generate a new service:
serverless create -t azure-nodejs --path <my-app>
Alternatively, you can use the
installcommand to create a new service, based on an existing GitHub boilerplate:
serverless install --url https://github.com/azure/boilerplate-azurefunctions --name my-app
You'll see the following files in your working directory:
service configuration is managed in the
serverless.yml file. The main responsibilities of this file are:
Define one or more functions in the service
eventssection to automatically create the resources required for the event upon deployment
You can see the name of the service, the provider configuration and the first function inside the
functions definition which points to the
handler.js file. Any further service configuration will be done in this file.
# serverless.yml service: azfx-node-http provider: name: azure location: West US plugins: - serverless-azure-functions functions: hello: handler: handler.hello events: - http: true x-azure-settings: authLevel : anonymous
handler.js file contains your function code. The function definition in
serverless.yml will point to this
handler.js file and the function exported
Create this file and add event data so you can invoke your function with the data
serverless invoke -p event.json
When you deploy a Service, all of the Functions, and Events in your
serverless.yml are translated into calls to the platform API to dynamically
define those resources.
To deploy a service, first
cd into the relevant service directory:
Then use the
To easily remove your Service from your Azure Functions account, you can use the
serverless remove -v to trigger the removal process. As in the deploy step
we're also running in the
verbose mode so you can see all details of the remove
Serverless will start the removal and informs you about it's process on the console. A success message is printed once the whole service is removed.
The removal process will only remove the service on your provider's infrastructure. The service directory will still remain on your local machine so you can still modify and (re)deploy it to another stage, region or provider later on.
The Serverless framework is usually installed globally via
npm install -g serverless. This way you have the Serverless CLI available for all your
Installing tools globally has the downside that the version can't be pinned inside package.json. This can lead to issues if you upgrade Serverless, but your colleagues or CI system don't. You can now use a new feature in your serverless.yml which is available only in the latest version without worrying that your CI system will deploy with an old version of Serverless.
To configure version pinning define a
frameworkVersion property in your
serverless.yaml. Whenever you run a Serverless command from the CLI it checks if
your current Serverless version is matching the
frameworkVersion range. The CLI
uses Semantic Versioning so you can pin it to an exact
version or provide a range. In general we recommend to pin to an exact version to
ensure everybody in your team has the exact same setup and no unexpected problems
# serverless.yml frameworkVersion: "=1.0.3" …
# serverless.yml frameworkVersion: ">=1.0.0 <2.0.0" …
If you already have a Serverless service, and would prefer to lock down the
framework version using
package.json, then you can install Serverless as
# from within a service npm install serverless --save-dev
To execute the locally installed Serverless executable you have to reference the binary out of the node modules directory.
node ./node_modules/serverless/bin/serverless deploy