DroneDeploy
Search…
App Development
With the App SDK Platform, we want to make deploying an app simple. This is why we have made creating Datastore tables, Functions, and Triggers configuration-driven using serverless.yml.
To follow along with this documentation, please checkout our sample apps.
DroneDeploy App SDK consists of four components:
    UI: Build a custom user interface
    Functions: Serverless architecture running on the DroneDeploy Platform. Write Node.js code to enable backend functionality.
    Datastore: Create custom data tables with columns and schema. Store customer data securely.
    Triggers: Build DroneDeploy event driven use cases.
Deploying these components separately can be a pain, thus we've created a CLI for managing Apps and their deployments.
You will find instructions on how all of these pieces fit together below.

Prerequisites

Be sure to have gone through the Getting Started prerequisites and installation.

App Directory Structure

This is what the directory structure of your DroneDeploy App might look like. You can see an actual example with our IFTTT sample app.
1
├── app
2
│ ├── css
3
│ │ └── styles.css
4
│ ├── index.html
5
│ └── js
6
│ └── script.js
7
├── functions
8
│ └── webhook
9
│ ├── config.json
10
│ ├── dronedeploy.js
11
│ ├── handler.js
12
│ └── package.json
13
├── package.json
14
└── serverless.yml
Copied!

app

Note that at the top level we have an app directory. This directory is where your frontend UI code will live. You will find your HTML, Javascript, CSS here. Note that if you have multiple UIs in different App Zones, you many want to have subdirectories for each App Zone.

functions

The functions directory is where you put all of your DroneDeploy Functions. Note that you can have multiple Functions per App; however, we recommend that you use one Function with multiple routes to handle multiple actions.
Read more about Functions here.

package.json

The package.json file is where you define your NPM dependencies.
It is important to have the "main" field be dronedeploy.js as that is how the platform knows which file to run.
1
{
2
"name": "ifttt",
3
"version": "0.1.0",
4
"main": "dronedeploy.js",
5
"author": "dronedeploy",
6
"devDependencies": {
7
"@dronedeploy/dronedeploy-cli": "1.1.1"
8
}
9
}
Copied!
You will also need to make sure that your have the dronedeploy-cli installed as a development dependency to be able to deploy correctly using the CLI. If you do not already have the CLI defined as a dependency in package.json, you can install it by running the following command.
1
$ npm install --save-dev @dronedeploy/dronedeploy-cli
Copied!

serverless.yml

The serverless.yml file is the blueprint to your App. This file is where you will define Datastore tables, Triggers, and your Functions. This is the entrypoint for the DroneDeploy CLI to understand what you want to do with your App. The next section will talk in depth about the serverless.yml file.

serverless.yml

The dronedeploy-cli is built using the Serverless framework. The serverless framework uses the serverless.yml file for configuration.
1
service: IFTTT
2
3
provider:
4
name: dronedeploy
5
6
app: # APP ID GOES HERE
7
8
plugins:
9
- "@dronedeploy/dronedeploy-cli"
10
11
functions:
12
ifttt-webhook:
13
handlerPath: functions/webhook
14
handler: dronedeploy
15
memory: 128
16
events:
17
-trigger
18
object-type: Export
19
type: complete
20
resources:
21
tables:
22
webhook-table:
23
description: "stores endpoint for IFTTT webhook"
24
columns:
25
- name: endpoint
26
type: Text
27
encrypted: false
28
length: 255
29
description: "webhook endpoint for IFTTT"
Copied!
service should be set to a reasonable name for your app.
provider should always be dronedeploy since you are deploying your serverless functions on the DroneDeploy Platform.
app is where you put the App Id of your DroneDeploy App. You can find your App Id by navigating to the App description page on the DroneDeploy App Market.
plugins should always be set to @dronedeploy/dronedeploy-cli. This lets the serverless framework know to use the dronedeploy-cli as the plugin.
functions is where you define your functions.
    The key is used as the name of the function. In the example above, the name is ifttt-webhook.
    The handlerPath lets the CLI know where to find your function files.
    The handler defines the module to run in your dronedeploy.js function file. Typically this field should stay as dronedeploy.
    Under events you can define your DroneDeploy Triggers. You can learn more about Triggers here. Note that you can have more than one Trigger defined.
    Finally you can define Datastore Tables under resources. Each table can have multiple columns. You can learn more about Datastore tables here.

Deployment

With the DroneDeploy CLI, you can deploy your Functions, Datastore tables, and Triggers with one command:
1
$ serverless deploy
Copied!
Once you run serverless deploy, your app is now ready for use.

Function Status

Once your Function has been deployed, you can check its status by running:
1
$ sls status
Copied!

Running Locally

Running functions locally is extremely simple using Google's functions-framework.
cd into your actual function folder
1
$ npm install @google-cloud/functions-framework
2
$ npm install
Copied!
Add a start script to package.json, with configuration passed via command-line arguments:
1
"scripts": {
2
"start": "functions-framework --target=dronedeploy"
3
}
Copied!
Note that your package.json will look something like below. Note the main and scripts fields, they indicate the entry file and point for your function.
1
{
2
"name": "ifttt-webhook",
3
"version": "0.1.0",
4
"description": "",
5
"main": "dronedeploy.js",
6
"author": "dronedeploy",
7
"license": "MIT",
8
"dependencies": {
9
"@dronedeploy/function-wrapper": "1.2.3",
10
"@google-cloud/functions-framework": "^1.6.0",
11
"dotenv": "5.0.1"
12
},
13
"scripts": {
14
"start": "functions-framework --target=dronedeploy"
15
}
16
}
Copied!
Next, run the following:
1
$ npm start
2
...
3
Serving function...
4
Function: dronedeploy
5
URL: http://localhost:8080/
Copied!
You should be able to send requests to this function using curl from another terminal window. Note that you can generate an authentication token from the CLI which you can pass in as a bearer token to authenticate your function request.
1
$ sls getAuth
Copied!

Logs

Once your Function is up and running, you can check its logs with the following command:
1
$ sls logs --functionName ifttt-webhook --tail
Copied!
You can find all CLI commands by running the following:
1
$ sls help
Copied!
Last modified 1yr ago