Add support for webhooks/callbacks

[skjdghsdjgsdj]

When we use Baby Buddy, we interact with it a couple ways: the web interface and the API through various integrations (Android app, custom devices, etc.). What would be nice is support for webhooks in the API.

Use case: we log a feeding one of three ways:

• Directly in the web interface
• Via the Android app
• Using a custom-built ESP32 device that uses the REST API

But, regardless of how we log the feeding, we'd like to get a webhook callback to an arbitrary HTTP(S) URL. That would let us set up a timer (outside of Baby Buddy) that notifies us after a certain time interval like two hours "hey, it's been a while, a feeding time is coming up shortly."

That's a specific use case around feeding, but a generic publish/subscribe mechanism would be nice for things like feedings, changes, etc. Another random example: a webhook around changes could let us separately keep track of likely number of diapers used, and then we get notified "hey, you've logged n changes which probably means n diapers and you might be running low."

I searched the docs and existing issues and didn't see this implemented or requested yet.

[cdubz]

I’m surprised there isn’t a more mature Django package for this. I’m open to this but it will take some research and consideration.

[skjdghsdjgsdj]

A potential idea, and shoot it down as you feel: MQTT support?

For example, for a simplistic initial use case, define an MQTT broker in a config file. Then if any of the REST endpoints are hit, publish the HTTP verb, endpoint, and its payload to the broker. I have a Mosquitto instance available, and if Baby Buddy was just dumb--in a good way--and republishes the REST requests it gets to the MQTT broker, then another service can subscribe to the broker and take over from there.

This way, the solution is loosely coupled and not require Baby Buddy to actually send its own outbound HTTP messages to arbitrary endpoints, and MQTT is by its nature a very light protocol.

The MQTT payload could be as simple as a JSON struct like:

{
    "endpoint": "/api/changes",
    "verb": "POST",
    "payload": "(original payload)"
}

Logically, only non-idempotent would need to emit events. I can't think of a scenario where a GET would need to be relayed, but ¯\_(ツ)_/¯ .

Of course there could be information exposure, so after a basic implementation, maybe the MQTT relaying could be locked down to specific endpoints, users, etc., but it would be a nice starting point.

The de facto standard library for MQTT in Python seems to be https://pypi.org/project/paho-mqtt/ which I've used before and was pretty straightforward, at least as a subscriber

[cdubz]

Webhooks I have at least a passing familiarity with but MQTT is entirely new to me. This looks and sounds interesting but I'd probably have to lean on someone else contributing actual code here. As with webhooks -- I'm open to it, just can't say it's something I'll have the time to jump on. Though MQTT has piqued my curiosity for sure 😄

[skjdghsdjgsdj]

I may mess with it and see what’s possible. Doubtless whatever I contribute would need to be cleaned up by someone, but hey, that’s how this open source thing goes. In the meantime I’m going to donate because this software has been amazing for us and definitely helped improve our sanity taking care of our new baby!

[cdubz]

Appreciate the support! And happy to help review code and move the idea forward. Will be a good way to learn about MQTT myself, hah.