Quickstart

In addition to the Console UI and the Serverless Toolkit, you have the option of directly using the Serverless API to create and manage your Services, Functions, and Assets. This empowers you to create custom build and deployment automations to suit your specific needs.

Get an overview of the API and the Serverless Toolkit by watching our overview video from Twilio Signal 2019:

Great. Let's have a look at how to deploy a single Function via the API.

Deploying a single Function

Create a Service

First, we'll create a Service, which serves as our container for the environments we set up.

We'll get back a Service SID, in the format ZSxxx.

Create an Environment

Next, we'll use that Service SID to create a "dev" Environment.

This will give us an empty environment, e.g. demo-X4HX-dev.twil.io. To see the domain name for your environment, you can fetch your environment using the ZExxx SID output from the prior code sample.

Create a Function

Now let's create our Function. We create the Function at the service level, not inside a particular environment (we'll deploy our Function to an environment later on). Also, we only set the name for the Function at this step. We'll choose a path, visibility, and upload the code for the Function in later steps.

You will get back a Function SID in the format ZHxxx. Save this Function SID for the next step, where we'll create a Version for this Function.

With a Function created, we're ready to create our first Version. Versions of Functions or Assets are where you add the path, visibility (public, protected or private), and the file content itself.

First, we need some code upload. Let's write a simple Function that decides the fate of the universe:

exports.handler = (context, event, callback) => {
  const sparedByThanos = Math.random() > 0.5;

  callback(null, {
    sparedByThanos,
    quote: 'You should have gone for the head.'
  });
};

Now we have a Function worth uploading. Save this as a file on your computer named firstfunc.js.

Now we can upload that file. The create API action is not currently represented in the helper libraries, so you have to do a manual file upload in the language of your choice. See an example below using Node.js.

Remember to replace ZSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with your Service SID, and ZHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with the SID of the newly created Function (from this step).

With the upload complete, you will see a SID logged to your terminal. Save this Version SID for the next step.

Create a Build

Now, we need to create a Build. A Build will compile Function and Asset Versions into a single, deployable package. This build will live in the Twilio cloud, so you just need the Build SID to reference it -- there are no files to keep track of.

You'll receive a result straight away, but note the status property. We need to wait until the status returns completed before continuing. The best way to handle the status changes is to poll every second or two. Here is some sample code to get the current status of a Build:

When the build is completed, we're ready to deploy!

Create a Deployment

For the final step, you must associate the Build we just created with the Environment we created earlier in this tutorial. (Remember the Environment SID!) This is called a Deployment.

Your Function will now be live and accessible via URL! You can test it out by going to its URL, such as https://demo-X4HX-dev.twil.io/thanos (be sure to replace demo-X4HX-dev.twil.io with the unique domain name for your Environment, which you fetched earlier).

Adding dependencies

When creating a build, you can also specify any dependencies that your code may have.

To do so, include the dependencies property, which must be a JSON stringified array of package names and versions.

Handling Asset uploads

The pattern we used above for uploading Functions is exactly the same as it for Assets.

1. Create an Asset
2. Create the Asset Version via a POST request to the serverless-uploads.twilio.com domain
3. Include the AssetVersion SID(s) we want to be a part of the Build, alongside any functionVersions and dependencies we might need.

What's next?

Definitely take a look at the API reference section for all of the API resources below. You might be particularly interested in Variables to allow setting Environment Variables for a given Environment.

• Service
• Environment
• Function
• Function Version
• Asset
• Asset Version
• Variable
• Build
• Deployment