Comparison with similar projects¶
Django Vox is great if you:
- Have content authors who are not programmers
- Use a current versions of Django/Python
- Want to be able to send notifications by multiple protocols
- Don’t need “web-scale” (tip: if you’re using Django, you don’t need “web-scale”)
- You don’t want to maintain a separate web service
That said here’s a more in-depth comparison between Django Vox and some specific alternatives.
- Pinax notifications
- Upsides
- Less setup
- Comes with notification settings editor
- Optional localization
- Downsides
- Templates are part of django’s template system, so you can’t edit them from the admin.
- Template parameters must be specified whenever sending a message. You need to know ahead of time, what parameters the template authors might want down the road.
- Notification recipients must be users
- Only supports email
- Doesn’t support HTML email
- Neither
- Notification types can be created anywhere in the code, this means more flexibility, but potentially more confusion too.
- Upsides
- django-courier
- Upsides:
- Uses signals, so you don’t have to specify your own notification types
- No code required
- Downside
- Only supports emails
- Doesn’t support HTML email
- The documentation is very lacking
- Specifying addresses is convoluted
- Maybe dead
- Requires
django.contrib.sites
- Upsides:
- universal_notifications
- Upsides:
- Supports many backends
- Built-in unsubscribing API
- Downsides:
- Backends have to know about the structure of the user object
- Notification recipients must be users
- Email subjects are hard-coded
- Templates aren’t easily editable in the admin
- Upsides:
- django-herald
- Downsides:
- Templates are part of django’s template system, so you can’t edit them from the admin.
- Notification subjects are stored in the code
- Only supports emails
- Notification recipients must be users (though its possible to work around this)
- Downsides:
- django-notifier
- Upsides:
- Easy setup
- Downsides:
- Only supports emails by default
- Doesn’t support HTML email
- Notification recipients must be users
- Custom backends must make assumptions about structure of user object
- Upsides:
- django-notifications
- Upsides:
- Supports more backends
- Supports filters
- Downsides:
- Old, and depends on an long-out-of-date version of django
- Notification recipients must be users
- Upsides:
- django-heythere
- Downsides:
- Notification types and templates are stored in
settings.py
- Only supports emails
- Doesn’t support HTML email
- Notification types and templates are stored in
- Downsides:
- django-push-notifications
- Upsides:
- Supports push notifications
- Downsides:
- Only supports push notifications
- No templates
- Notification recipients must be users
- Upsides:
- django-sitemessage
- Upsides:
- Supports many backends
- Downsides:
- Configuration is done in code
- Not possible to specify different messages for different backends
- Upsides:
- django-gcm
- Downsides:
- Like django-push-notifications but worse
- Downsides:
- django-webpush
- Downsides:
- Like django-push-notifications but only supports web push
- Downsides:
- django-scarface
- Downsides:
- Like django-push-notifications but worse (requires Amazon SNS)
- Downsides:
Actually Not Similar Projects¶
There’s also a good number of notification frameworks that solve a seeming-ly similar, but different problem: in-app notifications and activity feeds. These are the sort of things that might be a back-end to Django Vox. They’re listed here for completion:
- django-notifications-hq
- Stream Django (getstream.io)
- Stream Framework
- django-notify-x
- Django Messages Extends
- django-stored-messages
- django-user-streams
- django-knocker
- django-subscription
- django-offline-messages
- Django webline Notifications
- django-nyt
Also, of honorable mention is Kawasemi which is more of a logging system than anything else.