Functions
Functions enable you to write code or leverage existing integrations to address your business needs without spinning up your own servers or incurring an increased latency through call-outs to an external server or serverless technology. The code you write or use runs within PubNub's operational environment, giving you the scale and speed you need for your applications.
PubNub offers Functions in two versions (v1 and v2) that differ in terms of scope, terminology, UI flow on the Admin Portal, and library or REST API access.
Function versions
This document details the UI for Functions v2 that are accessible for new PubNub Functions users. To learn about the differences between both versions, refer to the Functions v1 vs. v2 comparison.
The steps for creating a Function also differ depending on the version. For details, refer to Development Guidelines v1 and Development Guidelines v1.
Packages
Before creating a Function, you must create a Package
Package
A collection of Functions (v2) used to manage and control a set of Functions.
Depending on whether you create a Package from scratch or use one of the built-in integrations, the Package you create is labeled as Custom
or Template
.
Functions
You can create a Function as part of the Package creation wizard by providing the Function's name, an event type which should trigger it, and a channel name on which it should run (either one channel or an up to 2-level channel wildcard pattern, like foo.*
).
Channel selection
If you want Functions to run on a larger number of channels, choosing wildcards over single channels is recommended. Note that Functions v2 has a fixed limit of 5 deployments (free accounts) or 30 deployments (paid accounts), which means that you can deploy a Package Revision with Functions on a maximum of 5 or 30 keysets respectively.
Once a Package is created, you can also open its specific Revision and add or delete Functions to/from it.
Test Functions
The Debug tab in the Function's editor lets you test the Function by sending a sample payload and analyzing the response.
Export logs through Events & Actions
Any running function publishes its logs to an internal blocks-output-*
channel, like blocks-output-NSPiAuYKsWSxJl4yBn30
(you can find this channel name in the Console output).
This channel has a 250-line limit. After exceeding the limit, new logs overwrite the old ones.
If you don't want to lose track of your logs and set up your own limits, you can use Events & Actions to export logs to an external service using the Webhook or S3 action.
To do that, follow these steps:
-
Set up an event listener to listen for events on the internal channel. Provide the following configuration and enter the correct
blocks-output-*
channel from the Console output in the Condition value field. -
Create either a Webhook or S3 action and add the created event listener to it.
When configuring this action, you can use the Batching feature to send multiple events in a single request.
Revisions
Each Package can have multiple Revisions that denote different versions of those Packages.
Once you create a Package, an initial Revision is automatically created for it. Any change in a Function included in this Package Revision (like code modification or changing a type of an event that triggers the Function) automatically creates a new Revision upon saving the changes.
Deployments
To run a Function, you must deploy a specific Package Revision. For example, you can have a Revision in which you test the Function's configuration, and once it's ready, you can deploy it as production-ready.
To be able to deploy a Package Revision, you must select keysets for which the Function(s) in a Package should run.
You can deploy a Package Revision on a maximum number of 50 keysets, which gives a fixed limit of 50 deployments for any Package Revision.
Permissions
Your level of access to Functions depends on the role you are assigned in the Admin Portal.
If you want to assign another user access to Functions on your account, you must assign them either the Functions developer or the Functions viewer role. This user must already have one of the standard roles assigned to their account: Account Admin, App Viewer, App Admin, Key Viewer, Key Admin.
For details on what actions each of these roles enables, refer to this table:
Permission | Functions developer | Functions viewer |
---|---|---|
View Packages | Yes | Yes |
View Revisions | Yes | Yes |
View deployments | Yes | Yes |
Create Packages | Yes | No |
Update Packages (rename) | Yes | No |
Create Revisions | Yes | Yes |
Update Revisions (rename) | Yes | No |
Assign Revisions to keysets (create deployments) | Yes | No |
Import Packages from the Integrations Catalog and assign to keysets (create deployments) | Yes | No |
Manage secrets on keysets | Yes | Yes |
Start deployments | Yes | No |
Stop deployments | Yes | No |
Rolling update deployments | Yes | No |
Delete deployments | Yes | No |
Delete Revision | Yes | No |
Delete Package | Yes | No |