Function as a Service (FaaS) is a growing trend in cloud computing. It's an opinionated approach to helping users write cloud applications that scale. A central tenant of cloud functions (and what really makes them effective) is their stateless nature. They handle requests then disappear. Nothing is ever permanently "on" which is why they're so cost effective for the cloud provider to host and manage.
Of course, there are times when it does make sense to handle state. But this does not mean you should clutter your stateless function code with state-related functionality. This is better left to an orchestration engine or similar event-driven strategy that is external to your cloud function. This gives you a proper separation of concerns between what is stateless and what is not (which is what you're really after with serverless architectures). I'll use the remainder of this post to detail how we do this in Intwixt.
Step 1. Create a Cloud Connector
Launch the Intwixt Web app (https://my.intwixt.com). Click the global menu link in the top-right corner and choose the menu item, CONNECTORS. When the page loads, choose the tab, CLOUD FUNCTION CONNECTORS. The cloud functions you connect will be listed here.
Begin by clicking the link, Connect a Cloud Function, to open the Connect Cloud Function wizard.
Enter a unique name to identify your cloud function within Intwixt. This will become the connector alias that Intwixt uses as you reference it in your flows, so choose something concise and descriptive. We also recommend you choose a relevant icon as it is used to represent your cloud function visually within a flow.
Once you are satisfied with the settings, activate the SIGNATURE tab. Enter a URL and choose the HTTP Method. This example uses an HTTP GET.
The next step is to define any header or query parameters. The GetWeather function being connected requires three HTTP query parameters:
- lat | the latitude
- lon | the longitude
- units | The temperature units (imperial)
Defining a basic schema is relatively straight-forward and requires no more than a comma-separated list of field names. You can add more detail, but most schemas can be defined using nothing more than a comma. I'll also add a default value (imperial) by using an exclamation mark as a flag (!imperial). Refer to the Intwixt Docs for a full list of escape characters.
The final step for the signature definition is to define the body (what will be returned from the cloud function when called at runtime). Because the JSON output is complex, it's easier to define the model by using a sample JSON document. Paste the sample JSON and then click DEFINE FIELDS.
The wizard will parse the JSON into the necessary model definition. You can make further edits to the generated model as necessary to fully customize it to fit your needs.
With the signature now defined, the next step is to define security fields (if required by the cloud function). Security field values are managed separately from connectors. This ensures your credentials are properly externalized and encrypted by Intwixt and available for use only when your flow is invoked at runtime.
The GetWeather cloud function being used in this example has one security field named appid. It must be passed as an HTTP query parameter. I will add a flag to this field to designate it as a password field (:password). This makes sure that the field values cannot be seen when entered by the user (an HTML password input type)
The final step is to include a link to the cloud function source page. This will be surfaced in the Intwixt designer, allowing me to link to the cloud function source for easier debugging and testing. Use the LINKS tab to add this optional value as shown here.
Click the IMPORT button to finalize your choices.
Step 2: Create A Credential
The GetWeather cloud function requires a security credential which I'll create now.
Click the global menu link in the top-right corner and choose the menu item, CREDENTIALS. When the credentials page loads, click the button, CREATE NEW to load the Create Credential Dialog. Choose the connector you just created from the list of options (e.g., GetWeather).
Once the connector is chosen, the credential settings will be shown. Complete every field. The one custom field, appid, is the field that was defined just a moment ago when the connector was created. I need to include the security key required by the cloud function as shown here. (Notice how Appid is a password field. This is due to the configuration choice made when the connector was created.)
When done, click CREATE to complete the session and dismiss the dialog.
Step 3: Design a Flow
The last step is to design a flow that will invoke the cloud connector.
Click the global menu link in the top-right corner and choose the menu item, FLOWS. When the flows page loads, click the button, CREATE > GENERIC FLOW to load the Create Generic Flow Dialog. Enter a title and then click CREATE. A new blank flow will appear in the designer.
Click the "+" icon in the upper left to add a trigger to the canvas. Click the HTTP RECEIVER button to allow this trigger to be invoked over HTTP. This will make it easy to test the flow directly from the designer.
Once the trigger type has been set, drag the "+" icon from the upper-left until it connects to the Receive Message tirgger. When the type selection panel loads on the right, search for the new connector (e.g., GetWeather).
Click the GetWeather result item (shown above) to reveal the activity of the same name. Click it once more (shown below) to complete your selection.
The activity icon, title, and settings will now be applied. Click the SETTINGS tab on the right side to reveal the Credentials. Take note that the credentials that were created in the prior step have been automatically selected. Note number 2 in the flow. This denotes that this newly added activity has 2 missing values. If you do not see this value, click the refresh icon.
The number, 2, is shown because the activity is missing two required inputs: lat and lon. The units field already contains the default value that was set when the connector was created (imperial). Click on the INPUT tab in the UI to reveal these two empty fields.
I could enter static values, but it's better to pass latitude and longitude to the HTTP Receiver trigger and run the test repeatedly with different values. I need to use the mapper.
Select the Receive Message trigger in the canvas and click the SETTINGS tab.
Click on the Request Model dropdown field (highlighted above). This will expand a list of options. Choose Create new local model to open the Create Model Dialog.
When it loads, provide a comma-separated list of field names (lat, lon) and then click the CREATE button.
The new model will now appear in the right panel. It shows the fields, lat and lon (which are now required when a request is made).
Now that the HTTP Receiver defines these fields, downstream activities can map to their values.
I begin by clicking the target activity in the canvas (GetWeather) and selecting the INPUT tab. I expose the mapper and upstream data by typing the "@" symbol. This triggers a list of all possible mapping inputs. Choose Lat as the mapping value for the Lat field and Lon for the Lon field.
All required configuration is now set (and the 2 to-dos that were once in the designer are now gone). Run a test by selecting the Receive Message trigger in the designer canvas and then activating the TEST tab. Activate the flow by clicking the start link ("Remember to start it before testing"). A message will appear, letting you know when the flow is fully activated (usually in under a second).
Enter test values for latitude and longitude and then click SUBMIT to run the test. (The flow does not yet contain a Return activity, so there will be no HTTP output except for an acknowledgment message with the job ID.)
In order to see the results, click the menu button in the lower left corner and choose Activity Log.
When the Activity Log loads, expand the messages to reveal the message exchange and test results.
A single step flow isn't very interesting, but it begins to reveal what's possible as you connect multiple services into cohesive application units. Here, for example, is an extended example that begins by sending an SMS to a user and asking them for a city. When the user eventually responds, a cloud function is called that resolves the latitude and longitude for the provided city. The output is then passed to the GetWeather cloud function to get the final value.
Importantly, all cloud functions involved in the flow are stateless as intended. Only Intwixt has a notion of state, and once the interaction is complete, all vestiges disappear.