Firestore adds three new trigger destinations through an integration with Eventarc
Software Engineer, Firestore
Senior Product Manager Lead, Firestore
Firestore triggers, commonly referred to in industry as change data capture, is a popular feature that lets you trigger custom compute logic in response to Firestore document changes. This feature is commonly utilized to replicate Firestore document changes to third-party services, notify them of changes to Firestore documents, and archive deleted Firestore documents in a different storage system.
To support a broader set of Firestore triggering destinations, we’re excited to share a new integration with Eventarc. Through this integration, we’re adding support for three new Eventarc supported triggering destinations: Cloud Run, Google Kubernetes Engine (GKE), and Cloud Functions (2nd gen). The integration uses the CloudEvents format, which is a unified specification for describing event data. Support for these new triggering destinations is in addition to the existing Firestore triggering support for Cloud Functions (1st gen).
Let’s say that you’re building a chat messaging system on Firestore, and you want newly created chat messages written to Firestore to cause an invocation of another process elsewhere. Your data model might be similar to the example below:
In this case, let’s say we have a Cloud Run service named
hello that exposes an HTTP endpoint. The sample container provided by Cloud Run can serve this purpose. By navigating to the triggers tab in Cloud Run, we can create a new trigger which invokes this endpoint anytime a document is created.
When you configure a new trigger, you can also apply filters. The example below only triggers when a document is created under the
Chats collection in the
That's it! Now when documents are created in the
Chats collection, you’ll see that these documents are passed to the configured Cloud Run service named
hello almost immediately!
For more information on how to set up and configure Firestore triggers, simply check out our documentation.
Thanks to Juan Lara, Senior Technical Writer, Firestore, for their contributions to this blog post.