Characteristics of a Cloud Function

The defining traits of Cloud Functions, including their security model, customization options, and when (and when not) to use them.

Now that you know what a Cloud Function is, this page covers the traits that make Cloud Functions distinct, and the kinds of problems they're best — and worst — suited to solve.

Security

Cloud Functions provide a way to do custom processing without doing it on the end user's device.

A common reason to need this is calling an external service. You may want to call a third-party API in a UI Component, but you don't want the end user's browser to have access to the secret tokens needed to authenticate. Cloud Functions provide a safe place for that work: the credentials live encrypted in IXON Cloud configuration, the call is made from the server, and only the response your function chooses to return ever reaches the browser.

The same principle applies to anything privileged — sensitive IXON API operations, business logic you don't want to ship to the client, or data that should be visible only to certain roles.

Data persistence

Each Cloud Function gets its own Document Store (a private MongoDB collection) and its own Object Storage scope. No other Cloud Function can read or write your data. This makes Cloud Functions a natural fit for apps that need to remember things between calls — service logs, user-created records, uploaded files — without you having to provision an external database.

For details, see Data Persistence.

Customization

Cloud Functions are customisable through the IXON Cloud Functions SDK, which exposes your function's runtime context, IXON Cloud's API endpoints, and data persistence to your code. You can also bring in any third-party library you need from PyPI.

For details, see Cloud Functions SDK.

When should you use a Cloud Function?

For more information about this topic, check out the Cloud Functions: when to use them article.