Notification Service Extension is an interesting feature that can send plaintext or rich push notifications to iOS.
Is it available on Linux and macOS server side beside the pubsub method?
Perfect already implemented this here. For now, you could probably fork it to make it work with Vapor, but this would definitely be a good thing to implement for Vapor — especially since a lot of newcomers are iOS developers.
Hey guys, we'll definitely have more integrated support coming soon. The perfect implementation has way too many dependencies for us to bring in, but there are also a couple examples from our own community. I can't find them now, once we get 1.0 out, we can dig into this more.
Initial perusing:
https://github.com/alexeyxo/swift-apns
@LoganWright Was unable to make that work for now 😢
I suggest using a Push provider
You will discover later on, that having logs over pushes with payloads is super important.
Also Android support require no changes to your backend. They also have support for sending push to many users in 1 api call and making groups/segments/tags for easy distribution to groups
https://onesignal.com/ is a trending and free option
My company uses https://www.urbanairship.com/ which is paid.
But there is 15+ options
@Casperhr I don't prefer that, I prefer a direct method (APNS/GCM) because of the extra features it provides (Not only push notifications, also downstream messaging, data providing, ect.)
You have a lot of these feature through the providers also.
But fair.
I would prefer a default implementation as well as community modules supporting third party providers. Writing an extension for a 3rd party system should be fairly straight forward.
@gregpardo I think there are some existing mac / ios solutions out there. My initial instinct is that we grab one that kind of works and fork/modify as needed. If they're universal, the author would probably appreciate the PR.
I really don't understand this.
I know for a fact that non of our competitors or us have direct push notifications integrated in any projects.
You need to have queues running as soon as you get a bit of users.
So either pick a push provider or setup a dedicated application just for this.
With all push providers, you don't even have to store the device tokens. And users will get notified on all their devices at the same time. Without coding anything!
Imo It's like building a mail/sms server all over
@Casperhr I know a lot of companies who like to handle push notifications themselves. True, it'll have queues once you have a bit of users and if necessary everything can run separately in a different app or thread (yey swift! ;P)
I think it's the best to give developers/users a choice ;) If they want to do it themselves, sure let them and provide a way to do so, otherwise if you think it's too much of a hassle, use a push service. Personally I also like the challenge to do it myself and I don't have to rely on external services. Perfect has a great direct push notification library: https://github.com/PerfectlySoft/Perfect-Notifications
Ok I get that point.
But I rather not copy all features Perfect does. Specially if I do not agree on it. I rather want Vapor to a framework where we do few things VERY well, instead of trying to solve every single issue half
If you rarely send push notifications then using a 3rd party is a dependency that you might not want. A lot of enterprise companies prefer to stay away from 3rd party integration. If you work at a small startup it might make sense though.
No matter what, I personally believe that we should have a native approach without outside services for notifications. @Casperhr If you're concerned about doing a few things very well, then let's just fork or make an adapter for any of these other APNS implementations for Vapor. There's no need to completely rewrite it. Modularity _is_ after all one of Vapor's key features that it's very good at; why not take advantage of it?
I think my point is
Sending the push notification through apples api is not really the hard part. There is so much more to it!
If this brings value to some developers fine by me. Just saying I would never recommend using it for any of the projects we build or consult for.
@Casperhr Mind elaborating on the reason you wouldn't use it for your projects? Is it just because Urban Airship (or whatever the cool kids use now and days) is more heavily stress tested and better supported?
@NathanFlurry
Urban airship is not really the cool kid in the block, it's more enterprise without being Azure :)
Onesignal is the cool kid and free!
So if you decide to do push from scratch. You need to deal with following which you don't need with a pusher provider
1) Storing of device tokens in your db / make api for this. It's a 1:n relation, since users can have several devices
2) Delete device tokens when Apple tells you they are invalid
3) The apps needs to keep a fresh token and send it to api, with plenty of errorhandling (No token, no push)
4) When you want to send push to many users, you have to loop device tokens. This will be very slow with 100k+ users, queues with many workers should be used here to send out push at the same time. Providers do have this. Users receive push notifications within seconds even at 100k+ scale
5) When you want to send a push to user "1", you need to look up all his device tokens and loop them, providers have tagging systems. Send push to tag "user_id_1" fx
6) Build a log system to store send push and responses from apple. So you can actually debug possible errors. This will be needed for any serious project!
7) Dealing with several environments. Can use several push apps, with different certificates for sandbox, adhoc and production
On top of that you most likely want GCM / FCM / WNS support also. Which is more integrations, different rules.
You end up spending a lot of hours on building something worse than the providers.
Just like we use
For us it's all about spending our clients money on building unique software for their app. We use services for rest.
Tori (https://github.com/boostcode/Tori-APNS) looks like it might be worth checking out for APNS. Looks a bit more stripped down for basic push notifications
Started doing some stuff over here https://github.com/matthijs2704/vapor-apns
Welcome to help! :)
Based on the new token authenticated push notifications, instead of certificates, only thing really needed now is a working HTTP/2 client...
Hmm I might be able to use that CCurl library 😃
Will GDC or libdispatch supported on APN which might start make sense for
heavy load.
On Mon, Sep 26, 2016 at 2:19 PM, Matthijs Logemann <[email protected]
wrote:
Started doing some stuff over here https://github.com/
matthijs2704/vapor-apns
Welcome to help! :)Based on the new token authenticated push notifications, instead of
certificates, only thing really needed now is a working HTTP/2 client...—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vapor/vapor/issues/606#issuecomment-249487963, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT-g_mO6rEtux9hbWsiMO69CsXKY5PIks5qt2QEgaJpZM4J9mWe
.
@wildfiremedia I'm creating this library/provider as a sync library. You can use GCD in your own code to make it async. But yes that is the thought! :)
It would be useful probably to have two libraries. One for the http client stuff to interact with Android and iOS push API and one to map with fluent to sync to the database and provide callbacks.
I've quickly hacked together an SDK for Pusher's push notification API. Pusher currently provides free unlimited notifications, which makes this the most approachable way to make the notifications work (both iOS and Android) to my knowledge. I hope you find that useful.
https://pusher.com/push-notifications
https://github.com/petrpavlik/PusherNotificationsSwift
I've also released VaporAPNS,An easy way to send APNS notifications in Vapor! :) https://github.com/matthijs2704/vapor-apns
I've also started working on VaporFCM (a library for Firebase Cloud Messaging, former Google Cloud Messaging)
We are opting to deprioritize this since @matthijs2704 and his vapor-apns package is currently fulfilling the role 👍
I guess now that @matthijs2704's repo is extremely out of date, is it time to reopen this? or will he approve the PRs already waiting to be upgraded to Swift 4 (and hopefully 4.2)?
There are two libraries for Push Notifications that I am working on, and that are both made for Vapor 3 and Swift 4.2
@anthonycastelli Thanks.
I'm currently working on adding a service to support sending push notifications through GoRush via its REST API. It must be very straightforward. It supports both APNS And FCM and is very performant. I've a working Docker with GoRush for my app and I'm trying to migrate to Vapor for my backend.
@mohpor That sounds quite interesting for me. Do you have an update on your progress? I'd be happy to take a look and help if I can.
Maybe someone who's interested in this topic will come here and might use this:
I just released a service for Gorush to easily use this as proxy to send push notifications.
You can find it here: https://github.com/code28/vapor-gorush
I'm happy for feedback and contributions!
FWIW, there's also work being done on an APNS protocol package built on Swift NIO called NIOAPNS. Assuming this package is finished and released, it would be easy for Vapor to offer an official APNS package built on top of this.
@tanner0101 Since you last commented, this one has been built :)
Most helpful comment
I've also released VaporAPNS,An easy way to send APNS notifications in Vapor! :) https://github.com/matthijs2704/vapor-apns
I've also started working on VaporFCM (a library for Firebase Cloud Messaging, former Google Cloud Messaging)