Triggers define how Applications are run. While you can always run an Application manually, Triggers allow you to run Applications automatically on a schedule or in response to some event.
This section will walk you through:
- Creating Triggers for your Application
- Detail on the types of Triggers CloudWright supports
# Creating a Trigger
To create a Trigger, click on the "Edit" button within the "Triggers" section of the editor sidebar:
Then click on the "New Trigger" button.
We'll cover the types of Triggers you configure in the following section.
# Types of Triggers
CloudWright supports the following types of Triggers:
Cron Triggers run your Application on a fixed schedule (for example, every minute, or every Tuesday at 4:00 PM). After you create the Trigger and publish, your Application will automatically be run on the schedule you specify.
The Cron Trigger configuration page looks like this:
The Name is just a label for the Trigger that will show up in various parts of the CloudWright UI.
You can select from a list of pre-configured Schedules (like "Once every minute"), or use your own custom cron string. On GCP, use 5-part cron syntax. For AWS, use 6-part syntax, with the added part being a the year. crontab.guru is a useful online tool to generate a cron string for you.
The Inputs section allows you to configure a fixed set of inputs that will be passed to your Application on each run.
You can have multiple Cron Triggers for a single Application. Each Trigger can have its own set of inputs.
HTTP Triggers create a URL that will run your Application when called. The output of your Application will be returned as the response to the HTTP request. There's a lot you can do with this Trigger, so let's list some examples before diving in:
- Create a lightweight API endpoint.
- Create embeddable webpages that render graphs from live data.
- Handle a request from a browser form.
The HTTP Trigger configuration page looks like this:
The HTTP Endpoint Address shows us the auto-generated URL we can use to call our Application.
Under Settings, we see the several mechanisms CloudWright exposes to control access to your Application:
Unauthenticated Public Access does what it says on the label -- it allows anyone with an Internet connection to call your function. While this can be useful, make sure it's what you want before enabling!
IP Controls allow you to restrict access to lists or ranges of IP Addresses using CIDR Notation. In this example, we're allowing traffic from
192.168.1.1 and any IP in the range
192.168.2.0 -- 192.168.2.255:
With Token Authentication, you can generate long-lived tokens that allow a user to authenticate with your Application. These should be passed as Bearer Tokens in the HTTP request (i.e., in a header of the form
Authorization: bearer <token>). If you add or remove tokens, you must publish your Application for the change to take effect.