Help Center/ FunctionGraph/ Developer Guide/ Development Tools/ Serverless Framework/ User Guide/ Service
Updated on 2023-11-22 GMT+08:00
View PDF
Share

Service

A service is like a project. It is where you define your FunctionGraph functions and the events that trigger them, all in a file called serverless.yml.

To build your first Serverless Framework project, create a service.

Organizing

For the beginners, you can use a single service to define all of the functions and events. 
myService/
  serverless.yml  # Contains all functions and infrastructure resources
As your application grows, you can split it into multiple services. Most users organize their services by workflows or data models, and group the functions related to those workflows and data models together. 
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 users want to keep those functions and resources together as a single unit of deployment for better organization and separation of concerns.

Creating

To create a service, use the create command. You can also input a path to create a directory and auto-name your service: 
# Create service with Node.js template in the folder ./my-service
serverless create --template-url https://github.com/zy-linn/examples/tree/v3/legacy/huawei-nodejs --path my-service

huawei-nodejs is an available runtime of FunctionGraph.

Check out the Create for all the details and options.

Contents

You will see the following files in your working directory:

  • serverless.yml
  • src/index.js

serverless.yml

Each service configuration is managed in the serverless.yml file. The main responsibilities of this file are:

  • Declare a Serverless service.
  • Define one or more functions in the service:
    • Define the provider the service will be deployed to (and the runtime if provided).
    • Define any custom plug-ins to be used.
    • Define events that trigger functions to execute (such as HTTP requests).
    • Allow events listed in the events section to automatically create the resources required for the event upon deployment.
    • Allow flexible configuration using Serverless variables.
You can see the name of the service, the provider configuration, and the first function inside the functions definition. Any further service configuration will be done in this file. 
# serverless.yml
service: my-fc-service

provider:
  name: huawei
  runtime: Node.js14.18
  credentials: ~/.fg/credentials # path must be absolute

plugins:
  - serverless-huawei-functions

functions:
  hello_world:
    handler: index.handler

index.js

The index.js file contains your exported functions.

Deploying

When you deploy a service, all of the functions and events in your serverless.yml are translated into calls to the Huawei Cloud API to dynamically define those resources.

To deploy a service, use the deploy command:

serverless deploy

Check out the deployment guide to learn more about deployments and how they work. Or, check out the deploy command docs for all the details and options.

Removing

To easily remove your service on Huawei Cloud, you can use the remove command.

Run serverless remove to trigger the removal process.

You will be notified of the process in the console when the removal starts. A success message is printed once the whole service is removed.

Only the service on your provider's infrastructure is removed during the removal process. 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.

Version Pinning

The Serverless Framework is usually installed globally via npm install -g serverless. Therefore, the Serverless CLI is available for all your services.

Installing tools globally has the downside that the version cannot be pinned inside the package.json. This can lead to issues if you upgrade Serverless, but your colleagues or CI system do not. You can use a feature in your serverless.yml without worrying that your CI system will deploy with an old version of Serverless.

  • Pinned version

    To configure version pinning, define a frameworkVersion attribute in your serverless.yml. Whenever you run a Serverless command from the CLI, it checks whether your current Serverless version is in 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 pinning to an exact version to ensure everybody in your team has the exact same setup and no unexpected problems occur.

    Examples

    Explicit version

    # serverless.yml

frameworkVersion: '2.1.0'
    Version range 
    # serverless.yml

frameworkVersion: ^2.1.0 # >=2.1.0 && <3.0.0

Installing Serverless in an Existing Service

If you already have a Serverless service, and prefer to lock down the framework version using package.json, then you can install Serverless as follows:

# from within a service
npm install serverless --save-dev
  • Invoke serverless locally
    To execute the locally installed Serverless, you have to reference the binary out of the node_ modules directory. An example is as follows: 
    node ./node_modules/serverless/bin/serverless deploy
Parent topic: User Guide