
Show HN: Apprise – A lightweight all-in-one notification solution - l2g
https://github.com/caronc/apprise
======
joshstrange
This is pretty cool, I drop the following shell script on all my servers:

    
    
        #!/bin/bash
        
        if [[ -z $1 && -z $2 ]]; then
            echo "No Message passed"
        else
            if [[ -z $2 ]]; then
                curl -s --form-string "token=MYAPPTOKEN" --form-string "user=MYUSERTOKEN" --form-string "message=$1" https://api.pushover.net/1/messages.json
            else
                curl -s --form-string "token=MYAPPTOKEN" --form-string "user=MYUSERTOKEN" --form-string "title=$1" --form-string "message=$2"  https://api.pushover.net/1/messages.json
            fi
        fi
    

It's SUPER basic and probably shitty but for me it's perfect. I can add " &&
push 'Command is Done'" to the end of any command and get a notification on my
watch/phone/(and desktop? But I don't have pushover on my desktop installed).
Great for things you threw into a screen/tmux session and want to know when
they finished.

------
harryf
Cool stuff! But what about AWS SNS
([https://aws.amazon.com/sns/](https://aws.amazon.com/sns/)) or Firebase Cloud
Messaging ([https://firebase.google.com/docs/cloud-
messaging/](https://firebase.google.com/docs/cloud-messaging/))?

~~~
noobiemcfoob
I'm not familiar with all of the services listed. Perhaps one of those
provides SMS messaging? (the main benefit of AWS SNS in my eyes).

------
l2g
Just a project I put together to make the many notification services out there
easier to use. I'd love to hear feedback and/or suggestions!

~~~
arendtio
Actually, I was wondering that there is no XMPP module.

~~~
l2g
No reason for this other then simply not having a request for it (until now)
:).

After some quick Googling, it sort of appears everyone uses this protocol
differently with different payloads (I could be really wrong here and would
love if someone were to weigh in here). For example Google Talk servers
require you to define additional XML which includes a token, where as other
services just require you to send the sub/pub standard XML. These differences
in payloads would make it difficult to build a simple URL with (while
following the current convention).

So rather than support XMPP, maybe it would be better to create a notification
per service you want to attach too? Did you have one in mind?

~~~
arendtio
Currently, I use a simple Go client [1] and a self-hosted XMPP-server
(ejabberd). In fact, I don't know what the Google servers require, but due to
the federated nature of XMPP (similar to e-mail), I think it would be best to
create a generic version rather than one for a specific service.

[1]:
[https://github.com/arendtio/xmppsend](https://github.com/arendtio/xmppsend)

~~~
l2g
Thank you for sharing this. I'll definitely investigate this further!

------
cmer
Awesome work, this is great! It seems like I have to write notification code
for every little project I build.

One that'd be interesting would be to have an Apprise "server" where all
config lives, and a client that receives commands. This way, a single Apprise
installation could service multiple hosts without having to duplicate
configuration files.

~~~
l2g
Hmm... I don't know if I'd want the headache of having everyone's passwords,
tokens and API keys on a server I managed and deal with the privacy that goes
with it...

But I was thinking of still supporting YAML or JSON formatted files to which
users could protect with permissions and store their personal data there
instead of being visible on the command line. the url would be something like
file://path/to/config.yaml or
[http://localserver/path/to/config.yaml](http://localserver/path/to/config.yaml).
So in a way, this kinda/sorta fits with your idea too :).

Thanks for your positive feedback!

~~~
cmer
I meant a self-hosted server, and self-hosted client.

------
bhargav
This is awesome! I work at a company where we have to abstract away from
multiple services like this. We face some interesting challenges and are
constantly learning from our experiences. I think you will have some similar
challenges and would love to hear your/HN community's thoughts on how some of
the issues would be tackled.

We are basically providing an API on top of multiple services which may work
their own way and have some idiosyncrasies.

\- I do not believe there is a specification/standard that is being followed
by all libraries (i.e: Do not think something like OpenID Connect exists for
these). Will we always be able to provide this API? What if we want to add a
service that requires slight adjustments?

\- How will we monitor and update our implementations when a single service is
updated?

Edit: Formatting.

Thanks!

~~~
l2g
What you're describing you're building might be more complicated then the
problems I faced.

For apprise, I focused on what was common across all notification services:
all of them had a body, most have a title, and some allow you to attach
images. Anything outside of these 3 fields then became very specific to that
one (notification) service. The sacrifice made is that if you want in-depth
functionality of a specific service with rich features, you won't achieve it
with apprise. It can however accomodate some additional attributes via
arguments... For example with email you can define the smtp server, from
address, etc., but that wouldn't be applicable to say Twitter.

I know I'm drifting from your question, but with respect to what was said: \-
enforce your own specification as you're right, you'll find everyone solves
great problems differently. \- use inheritance. Base classes make life soo
much easier. \- decide what is common or what you want to make common across
your API endpoints and stick with that. Like the body, title, image issue I
resorted too. Maybe you want to assume you'll always need a user and password
too. Prepare to support tokens and open ids out of the gate in your base class
\- don't try to extend on one endpoint too much regardless of how much feature
rich functionality it offers. Focus on getting them all endpoints working
using the standards you come up with. This will help you achieve your goal.
Build onto it after. \- unit tests! They're a pain to learn, but you won't
regret knowing your code remains stable!

As per monitoring, I presume you're running a web service at the end of the
day. So there are many great monitoring solutions out there that can check
your servers availability constantly. Nagios (or forks of it) for example can
email you when your service gets disrupted allowing you to take action right
away. Heck, Nagios+apprise and you can get a text message. There are lots of
more modern monitoring tools as well that can do all this for you.

Sorry for the wordy reply, I hope I answered your questions!

Good luck

------
rane
This seems useful. Is there anything like this for nodejs?

By the way, the logo on top of the README is not working.

------
jaaames
Looks great, not having a go at you, but instantly reminded me of this

[https://youtu.be/8wfG8ngFvPk](https://youtu.be/8wfG8ngFvPk)

~~~
l2g
Apparently this video is not available to be watched in my country (Canada).

But now that you struck my curiosity, what is the video about? :)

~~~
croisillon
it's about the cross-portal messaging system WUPFH.com from the US series The
Office

------
EGreg
Does it deliver notifications to phones in China where google FCM
notifications don’t reach?

~~~
l2g
No, unfortunately it only simplifies the use of existing notification
services.

I don't recall supporting a service that does that though. Perhaps I need a
wrapper for Twilio? That service may at least allow text messages to the
specific China phones you speak of... Not sure though.

------
monkeydust
Looks good. Ha What about WhatsApp via this
[https://developers.facebook.com/docs/whatsapp/](https://developers.facebook.com/docs/whatsapp/)
?

~~~
l2g
Thanks,

I'll look into this. I actually added Facebook support, but it was around the
time Zuckerberg got in trouble with data leaking. The API at the time became
utterly useless (for Facebook).

But I never looked into the WhatsApp side of things. Thanks for the idea!

------
kfdm
Sadly growl seems to be mostly obsoleted but it's cool to see my code show up
in a project like this

