Feature Request: Webhooks

[Robert Payne]

Hey Firebase Team,

I'm an iOS developer and need to frequently send push notifications and other things that Firebase cannot do when actions inside the database itself happen. I have a secondary server setup to handle these things and currently am planning on running most of my "writes" through it to ensure that I can hook in and send out notifications and sorts.

I was thinking though it would be even more awesome if Firebase could push out to webhooks if certain pieces of data change in the storage. Unfortunately running a websocket server-side isn't a solution since some of these data storage areas are not easily "monitorable" given the entire tree would have to be monitored since they are keyed by the user's id.

Is there better recommendation for implementing server-side hooks for these sorts of things? Or is NodeJS the recommended way and monitoring via a web socket?

Cheers,

Robert

[Michael "Kato" Wulf]

Hey Robert,

Great questions! This is something I've struggled with as well. I'm also using a node.js process to ferry data to different API's, such as an SMTP server. 

I've found the Firebase-work-queue pattern invaluable for this. I have the client "queue" an event, the node.js process "consumes" it, and fires off the third party API call. Then, based on the API's returned value, either replies with a success or failure by queuing a reply which is consumed by the client.

By relying on Firebase as the intermediary, and using a queue model, I can take advantage of some great benefits:

• There is no API service (HTTP server, etc) to maintain, just a consumer of Firebase events
• Multiple queue workers can be brought online in parallel, or dropped off at any time
• Unlike HTTP APIs, queue events aren't lost on server crash, they just hang out till someone shows up to consume them
• Clients can disconnect and still read the queue results when they return online
• This model is useful for many other consumables besides just third party API events

Hope that helps!

Cheers,

Kato

Michael "Kato" Wulf 

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Livsey]

I'm using the work-queue pattern in my app to great success, but it does add critical logic to the client code.

A recent post on the blog talked about using your Firebase database as your product's API, but if you've got any work-queues then this makes that much less attractive. Documenting "every time you do xxx, make sure to push an item to the queue which looks like yyy" doesn't make a great API!

Some kind of trigger would be awesome for this kind of thing. You can then carry on with a work-queue pattern but have Firebase populate the queue instead of relying on the client code.

This could work in much the same way as the security rules by attaching triggers to points of the tree (though I'd assume just on write and not read) and allow you basic commands to update/insert elsewhere in the tree. Ideally it'd be able to do different things based on create/update/delete but that's icing on the top!

Cheers.

[Michael "Kato" Wulf]

Hi Richard,

Thanks for the great notes about your use case. It is easy to fall into the double write logic with a queue.

There are a couple simple ways around this. First, you can skip the xxx write (from your example) and just do the queue write (let the worker thread take care of the data manipulation as well), which occasionally saves time and effort.

A second option is to create your own trigger; I use this in a couple project and they are extremely easy to manage yourself. Pretty much anything you could imagine being triggered from Firebase data can be done with a simple privileged consumer (worker).

For instance, my priv worker could listen on the online_users/ path for add/update/delete events and 'queue' actions (or skip the queue and just trigger API calls itself, depending on the complexity and volume). 

The great part here is that the worker script really has no "meat," just a few lines of code. Creating something resembling hooks becomes fairly trivial because Firebase is the central API and "servers" are really just data consumers with different privileges.

Cheers,

Kato

Michael "Kato" Wulf