WebSockets vs Push Notifications (AWS Pinpoint)

Hello all, I am developing a new mobile app with Flutter frontend and Phoenix backend. The mobile app has real-time task management and chat. The Flutter app will also be available on web and desktops.

I’m a little confused about the difference between using Phoenix WebSockets vs Push Notifications via a service like AWS Pinpoint.

Do Push Notifications handle chat on a mobile app? Or is that through WebSockets and the Push Notification is just the notification?

If it’s WebSockets, is the connection kept open when the app is in the background?

Appreciate any insights.

I am not aware of Push Notifications being used for chat features. Push notifications are from server->client, which means that you would not be able to send data back up from client->server with them (although you could make regular web requests for that). While push notifications are usually instant, I don’t think you’re guaranteed that.

Where Push Notifications shine is if you want to send the user an event while the app is not open. I’m not sure about Android, but iOS will not keep your WebSocket open while the app is closed. So if you want to get real-time updates, you would need to send them over APNS.

Our approach for a mobile app at work (server->client feed events) is to always send an APNS event for any new notification. When the client boots, it tells the OS that it wants to intercept the APNS event and then it discards it. Instead, it has a WebSocket connection using Phoenix Channels (React Native) that allows it to receive the real-time events via the WebSocket. The benefit of this, even though we’re not pushing data from client->server is that the infrastructure can be monitored by us and we can keep track of things like latency to push. We give that up if we relied only on APNS. We can also easily add new features that would require client->server without rethinking our approach.

4 Likes

With pull notifications, mobile apps are required to continually poll the developer’s server, connecting every few minutes to determine if new information is available. With push notifications, however, the cloud service acts on behalf of the app and only connects to the mobile device when there are new notifications. If the device is powered on but the app is not running, the service will still forward the notification. If the device is powered off when a notification is sent, the service will hold on to the message and try again later.

Also, push notification doesn’t handle the chat on your mobile app. If you want to notify about something in your app you can use that. Like every time user send the message and if a user has not open the chat app then it will notification like that you have received a “new message”

I recently implemented push notification in flutter for iOS. If you want to test it with firebase using APNS you can send a message from the firebase to your mobile.

If you don’t want to use firebase then you can send the notification from the Phoenix server also using Pigeon library.

2 Likes

Awesome thanks for this. So there’s no need for AWS Pinpoint if you are using Pigeon? Also we are not using Firebase as we would like to serve users in China where that is blocked.

I think you need something similar to firebase. So AWS Pinpoint can work. There is also amazon sns you can try.

1 Like

We use Pigeon at SalesLoft and have had 0 issues with it since we released using it. You register your APNS credentials and include them at runtime. It’s also free since it’s just using APNS.

I think that AWS Pinpoint may be for sending 1 notification and determining what method/device the user should receive the notification on?

No idea re: China in this case.

1 Like