Firebase Cloud Messaging (FCM) and its Push Notification Service
I mainly focus here to discuss Firebase Cloud Messaging(FCM). And give you some more idea about its push notification service.
Introduction
Firebase Cloud Messaging, formerly known as Google Cloud Messaging, is a cross-platform cloud solution for messages and notifications for Android, iOS, and web applications, which currently can be used at no cost.
Common capabilities and limitations
Types of messages that can be sent
1. Notification Message: Notification messages are handled by firebase SDK itself. Typically, the notification message contains a title, message, icon, etc., These messages can be sent from the firebase console UI. By sending this kind of message, you won’t get much control over the notification. The notification will be shown automatically when the app is in the background.
2. Data Message: Data messages have to be handled by the Android app. You can add this kind of message if you want to send some additional data along with the notification. But sending these messages through the Firebase console is not possible. You need to have a server-side logic to send the notification using Firebase API. You need to use a data key when sending this message.
The maximum payload for both message types is 4KB.
3. Messages with both notification and data payload:
· A message can also contain both notification and data payload. When these kinds of messages are sent, they will be handled in two scenarios depending upon the app state (background/foreground). For these messages, we can use both notification and data keys.
· When in the background — Apps receive the notification payload in the notification tray and only handle the data payload when the user taps on the notification.
· When in the foreground — App receives a message object with both payloads available.
Pricing
· Cloud messaging and In-App Messaging are Free of charge.
· But If we are using firebase functions to send messages, we have to pay for firebase functions as follows.
Cloud Functions
* Invocations — Free up to 2M/month. Then $0.40/million
*GB-seconds — Free up to 400K/month. Then Google Cloud pricing
*CPU-seconds — Free up to 200K/month. Then Google Cloud pricing
*Outbound networking — Free up to 5GB/month. Then $0.12/GB
*Cloud Build minutes — Free up to 120min/day. Then $0.003/min
*Container storage — No free usage. $0.026/GB
Message Latency
· The official video of Firebase Cloud Messaging says that 95% of your messages will deliver with an average time of 250ms
Messaging Delivery & Lifetime
· Can send messages by setting priorities.
· Receiving messages from multiple senders — FCM allows multiple parties to send messages to the same client app. For example, suppose the client app is an article aggregator with multiple contributors, and each of them should be able to send a message when they publish a new article. This message might contain a URL so that the client app can download the article. Instead of having to centralize all sending activity in one location, FCM gives you the ability to let each of these contributors send its own messages. Note that there is a limit of 100 multiple senders.
· Maximum message rate to a single device — You can send up to 240 messages/minute and 5,000 messages/hour to a single device. This high threshold is meant to allow for short-term bursts of traffic, such as when users are interacting rapidly over chat. This limit prevents errors in sending logic from inadvertently draining the battery on a device.
· Upstream message limit — We limit upstream messages at 1,500,000/minute per project to avoid overloading upstream destination servers. We limit upstream messages per device at 1,000/minute to protect against battery drain from bad app behaviors.
· Topic message limit — The topic subscription add/remove rate is limited to 3,000 QPS per project. For message sending rates, see Fanout Throttling.
· Then, you can configure Firebase to store and resend every message up to 28 days. Of course, losing a network connection for some time does not prevent a message to arrive.
· There is another limitation though: up to 100 messages can be stored per client. So, if there are more than a hundred, it’s better to re-request the diff.
Termination of message service
· The best approach it’s to use Firebase Analytics for Android with event logging which automatically log app uninstall using the app_remove event. You can find a complete list of automatically logged events for both Android and iOS here. So, you can find who uninstalled the application and who uses it. Then you can select what message and for whom to send that.
Multiple Notification feasibilities
· Fanout Throttling — Message fanout is the process of sending a message to multiple devices, such as when you target topics and groups, or when you use the Notifications composer to target audiences or user segments. Message fanout is not instantaneous and so occasionally you have multiple fanouts in progress concurrently. We limit the number of concurrent message fanouts per project to 1,000. After that, we may reject additional fanout requests or defer the fanout of the requests until some of them already in-progress fanouts complete. The actual achievable fanout rate is influenced by the number of projects requesting fanouts at the same time. A fanout rate of 10,000 QPS for an individual project is not uncommon, but that number is not a guarantee and is a result of the total load on the system. It is important to note that the available fanout capacity is divided among projects and not across fanout requests. So, if your project has two fanouts in progress, then each fanout will only see half of the available fanout rate. The recommended way to maximize your fanout speed is to only have one active fanout in progress at a time.
· Device Group Messaging — With device group messaging, app servers can send a single message to multiple instances of an app running on devices belonging to a group. Typically, “group” refers to a set of different devices that belong to a single user. All devices in a group share a common notification key, which is the token that FCM uses to fan-out messages to all devices in the group. Device group messaging makes it possible for every app instance in a group to reflect the latest messaging state. In addition to sending messages downstream to a notification key, you can enable devices to send upstream messages to a device group. You can use device group messaging with either the XMPP or HTTP connection server. The limit on data payload is 2KB when sending to iOS devices, and 4KB for other platforms. The maximum number of members allowed for a notification_key is 20.
· Multiple services that want to send notifications — If We want to make it as easy as possible for any service to be able to send a notification, without worrying about the multiple devices and providers.
· Can we use Rabbit MQ? — We can use RabbitMQ as an exchange for our job queues. We have a queue for each application ID and provider type.
This is important because we want to isolate failures for each application and provider type.
Reference: https://blog.gojekengineering.com/how-we-manage-a-million-push-notifications-an-hour-549a1e3ca2c2
Security of the communication
· Credentials
Project ID
A unique identifier for your Firebase project, used in requests to the FCM v1 HTTP endpoint. This value is available in the Firebase console Settings pane.
Registration token
A unique token string that identifies each client app instance. The registration token is required for single device and device group messaging. Note that registration tokens must be kept secret.
Sender ID
A unique numerical value created when you create your Firebase project, available in the Cloud Messaging tab of the Firebase console Settings pane. The sender ID is used to identify each sender that can send messages to the client app.
Access token
A short-lived OAuth 2.0 token that authorizes requests to the HTTP v1 API. This token is associated with a service account that belongs to your Firebase project. To create and rotate access tokens, follow the steps described in Authorize Send Requests.
Server key (for legacy protocols)
A server key that authorizes your app server for access to Google services, including sending messages via the Firebase Cloud Messaging legacy protocols. You obtain the server key when you create your Firebase project. You can view it in the Cloud Messaging tab of the Firebase console Settings pane.
Important: Do not include the server key anywhere in your client code. Also, make sure to use only server keys to authorize your app server. Android, iOS, and browser keys are rejected by FCM.
· Network Address Translation and/or Stateful Packet Inspection firewalls
If your network implements Network Address Translation (NAT) or Stateful Packet Inspection (SPI), implement a 30 minute or larger timeout for our connections over ports 5228–5230. This enables us to provide reliable connectivity while reducing the battery consumption of your users’ mobile devices.
· Communication Security
Developers already use HTTPS to communicate with Firebase Cloud Messaging (FCM). The channel between FCM server endpoint and the device is encrypted with SSL over TCP. However, messages are not encrypted end-to-end (E2E) between the developer server and the user device unless developers take special measures.
· FMC Protocols
Currently, FCM provides these raw server protocols:
· Legacy HTTP protocol
· Legacy XMPP Protocol
Your app server can use these protocols separately or in tandem. Because it is the most up-to-date and most flexible for sending messages to multiple platforms, the FCM HTTP v1 API is recommended wherever feasible. If your requirements include upstream messaging from devices to the server, you’ll need to implement the XMPP protocol.
XMPP messaging differs from HTTP messaging in the following ways:
· Upstream/Downstream messages
o HTTP: Downstream only, cloud-to-device.
o XMPP: Upstream and downstream (device-to-cloud, cloud-to-device).
· Messaging (synchronous or asynchronous)
o HTTP: Synchronous. App servers send messages as HTTP POST requests and wait for a response. This mechanism is synchronous and blocks the sender from sending another message until the response is received.
o XMPP: Asynchronous. App servers send/receive messages to/from all their devices at full line speed over persistent XMPP connections. The XMPP connection server sends acknowledgment or failure notifications (in the form of special ACK and NACK JSON-encoded XMPP messages) asynchronously.
· JSON
o HTTP: JSON messages sent as an HTTP POST.
o XMPP: JSON messages encapsulated in XMPP messages.
· Plain Text
o HTTP: Plain Text messages sent as an HTTP POST.
o XMPP: Not supported.
· Multicast downstream sends multiple registration tokens.
o HTTP: Supported in JSON message format.
o XMPP: Not supported.
· Authorize Send Requests
Requests sent to FCM from your app server or trusted environment must be authorized. Note these important differences between legacy HTTP and HTTP v1 API authorization:
· The FCM HTTP v1 API authorizes requests with a short-lived OAuth 2.0 access token. To mint this token, you can use Google Application Default Credentials (in Google server environments) and/or manually obtain the required credentials from a JSON private key file generated for a service account. If you are using the Firebase Admin SDK to send messages, the library handles the token for you.
· The legacy protocols can use only long-lived API keys obtained from the Firebase console.
You can get a better idea of the security background by tapping here.
Thank you, everyone. Hope you gain something from my story. Nave a nice day!
