Exploring Apprise instead of maintaining (n)th notification channels

[alexjustesen]

In short, I'm entertaining the idea of dropping all notification channels except database, email and webhooks in favor of integrating with Apprise for notifications.

This discussion and poll is meant to evaluate this decision as it would be considered a deviation and breaking change from the current state. Feel free to use the poll below as a quick yay/nay to voice your opinion and if you have further context please leave a comment as well.

👍 Pros

• Less notification channels I have to support which frees up capacity to work on features.
• 100+ supported notification channels: https://github.com/caronc/apprise?tab=readme-ov-file#supported-notifications

👎 Cons

• Will require separate setup of Apprise by users to integrate with services like Slack, Telegram and Discord.
• tbd...

Thanks in advance and I'm looking forward to hearing everyone's thoughts.

[pigers]

Maybe implement Shoutrrr ?

[alexjustesen]

I had considered it but since Shoutrrr was "inspired by Apprise" it made more sense to consider the more popular project.

[pigers]

yeah - if there's more rich project, then picking it up makes more sense !

[pigers]

had a look at apprise, that would require to provide good installation and configuration routine for users
it's documentation is confusing to read.

[armond-avanes]

I'm a heavy Apprise/Apprise-API user so I might be a bit biased.

I wouldn't call it separate setup for the existing notifications. All they have to do is to migrate their existing setup from something like
https://discord.com/api/webhooks/WEBHOOK_ID/WEBHOOK_TOKEN to discord://WEBHOOK_ID/WEBHOOK_TOKEN (and almost the same for Slack and other channels). And by the way, the migration process can be fully (or at least partially) automated as part of SpeedTest-Tracker version migration and the users won't even notice the change. Usually the URL formats are pretty standard and solid. They can be parsed and migrated to the new format.

The good thing here is that, by just migrating to this new setup format, you're going to get access to 100 more channels under the same roof as you've already mentioned! This is a great feature to have both for you as the project maintainer (less code to implement and less docs to maintain) and for the users to get instant access to several more channels which are not supported now.

UPDATE: Here is a consolidated list of supported notifications and their formats as part of Apprise docs: https://github.com/caronc/apprise/#supported-notifications

[armond-avanes]

I'm not a PHP developer at all, but doing a quick search reveals that it's pretty straightforward to call a python script from PHP. Here is one of those quick guides: https://www.tutorialspoint.com/run-a-python-program-from-php

Shouldn't be much of a problem to implement this integration.

[svenvg93]

This Docker file is only used for the development environment. The container is build by lsio which doesn't have python in their image.

I'm not a PHP developer at all, but doing a quick search reveals that it's pretty straightforward to call a python script from PHP. Here is one of those quick guides: https://www.tutorialspoint.com/run-a-python-program-from-php

Shouldn't be much of a problem to implement this integration.

It's indeed not a problem to call it from the application. The main "problem" is the extra dependencies.

@alexjustesen What are your thoughts on it?

[armond-avanes]

It's indeed not a problem to call it from the application. The main "problem" is the extra dependencies.

I understand your concern. But those extra dependencies are just kind of an isolated runtime and being utilized only when needed (and when Apprise CLI is called). They're not going to affect the main/existing PHP application, unless I'm missing something here.

[pigers]

why not create a stack of apprise and speedtest in yaml and call it a day ? other apps are having mariadb as part of stack required to run software and it's totally fine.

[armond-avanes]

why not create a stack of apprise and speedtest in yaml and call it a day ? other apps are having mariadb as part of stack required to run software and it's totally fine.

For me, it would be perfectly fine. I'm already running a standalone Apprise-API container to consolidate all my notifications config there.

But I doubt that people not familiar with Apprise ecosystem will find this useful. It's not even a database which makes sense to a major part of the user base. Imagine having to setup a second container (and thus forcing to use Docker Compose instead of plain Docker) just for the sake of sending notifications. I still prefer an internal integration of Apprise CLI within the main docker image. Much simpler and straightforward from users' perspective. Just my 2 cents.