Firebase Realtime Database Triggers
With Cloud Run functions, you can handle events in the Firebase Realtime Database in the same Google Cloud project as the function. Cloud Run functions lets you run database operations with full administrative privileges, and ensures that each change to the database is processed individually. You can make Firebase Realtime Database changes via the Firebase Admin SDK.
In a typical lifecycle, a Firebase Realtime Database function does the following:
Waits for changes to a particular database location.
Triggers when an event occurs and performs its tasks.
Receives a data object that contains a snapshot of the data stored in the specified document.
Event types
Functions lets you handle database events at two levels of specificity; you can listen specifically for only creation, update, or deletion events, or you can listen for any change of any kind to a path. Cloud Run functions supports the following event types for the Realtime Database:
Event Type | Trigger |
---|---|
providers/google.firebase.database/eventTypes/ref.write |
Triggered on any mutation event: when data is created, updated, or deleted in the Realtime Database. |
providers/google.firebase.database/eventTypes/ref.create (default) |
Triggered when new data is created in the Realtime Database. |
providers/google.firebase.database/eventTypes/ref.update |
Triggered when data is updated in the Realtime Database. |
providers/google.firebase.database/eventTypes/ref.delete |
Triggered when data is deleted from the Realtime Database. |
Specifying the database path and instance
To control when and where your function should trigger, you need to specify a path, and optionally specify a database instance.
Path
Path specifications match all writes that touch a path, including writes that
happen anywhere below it. If you set the path for your function as /foo/bar
,
it matches events at both of these locations:
/foo/bar
/foo/bar/baz/really/deep/path
In either case, Firebase interprets that the event occurs at /foo/bar
, and the
event data includes the old and new data at /foo/bar
. If the event data might
be large, consider using multiple functions at deeper paths instead of a single
function near the root of your database. For the best performance, only request
data at the deepest level possible.
You can specify a path component as a wildcard by surrounding it with curly
braces; foo/{bar}
matches any child of /foo
. The values of these wildcard
path components are available within the event.params
object of your function.
In this example, the value is available as event.params.bar
.
Paths with wildcards can match multiple events from a single write. An insert of:
{
"foo": {
"hello": "world",
"firebase": "functions"
}
}
matches the path /foo/{bar}
twice: once with "hello": "world"
and again with
"firebase": "functions"
.
Instance
When using the Google Cloud console, the database instance must be specified.
When using the Google Cloud CLI, the instance must be specified as
part of the --trigger-resource
string.
For example the following would use the following in your --trigger-resource
string:
--trigger-resource projects/_/instances/DATABASE_INSTANCE/refs/PATH
Event structure
When handling a Realtime Database event, the data
object contains two
properties that are provided in JSON object format:
data
: a snapshot of the data taken prior to the event that triggered the function.delta
: a snapshot of the data taken after the event that triggered the function.
Code sample
Node.js
Python
Go
Java
C#
Ruby
PHP
Deploying your function
The following gcloud command deploys a function that will be triggered by
create
events on the path /messages/{pushId}/original
:
gcloud functions deploy FUNCTION_NAME \ --no-gen2 \ --entry-point ENTRY_POINT \ --trigger-event providers/google.firebase.database/eventTypes/ref.create \ --trigger-resource projects/_/instances/DATABASE_INSTANCE/refs/messages/{pushId}/original \ --runtime RUNTIME
Argument | Description |
---|---|
FUNCTION_NAME |
The registered name of the Cloud Run function you are deploying.
This can either be the name of a function in your
source code, or an arbitrary string. If FUNCTION_NAME is an
arbitrary string, then you must include the
--entry-point flag.
|
--entry-point ENTRY_POINT |
The name of a function or class in your source code. Optional, unless
you did not use FUNCTION_NAME
to specify the
function in your source code to be executed during deployment. In that
case, you must use --entry-point to supply the name of the
executable function.
|
--trigger-event NAME |
The name of the event type that the function wishes to receive. In this case, it will be one of the following: write, create, update or delete. |
--trigger-resource NAME |
The fully qualified database path to which the function will listen.
This should conform to the following format:
projects/_/instances/DATABASE_INSTANCE/refs/PATH .
|
--runtime RUNTIME |
The name of the runtime you are using. For a complete list, see the
gcloud reference.
|