I'm designing the future notification system for an app, and wondering about how topic subscriptions work.
According to the documentation here the following note states:
Note: You can subscribe up to 1,000 devices in a single request. If
you provide an array with over 1,000 registration tokens, the request
will fail with a messaging/invalid-argument error.
Does that also mean that a topic can't have more than 1000 subscribers? Or would I be able to exceed that 1000 user limit if I register devices one by one?
From the docs:
Topic messaging supports unlimited topics and subscriptions for each app.
The note in this page, means the array can only have 1000 tokens in one request, if you add more than 1000 then you will get an error.
Related
Introduction
So from the official firebase docs. It states there that:
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.
The topic subscription add/remove rate is limited to 3,000 QPS per project.
qps = queries per second.
Now here's the thing. It says "per project". What if an app gets very popular and thousands of users open the app at the same time then click a button that subscribes to a topic or unsubscribe?
Wouldn't hitting the rate limit 3000 queries per second highly possible?
Here's my real question
Does firebase_messaging's subscribeToTopic(..) and unsubscribeFromTopic(..) methods automatically handle retries? (referring to "Retry with exponential backoff" above)
If not, then how would a very popular app handle topic subscriptions from a massive number of users?
Because the plugin does not provide any documentation about this.
Coming from a different platform (Android) for your question on subscribeToTopic() retry?, but possibly both function similarly. On Android it returns a Task where in Flutter it returns Future (Task = Future for Flutter if I understood that correctly), which I presume is a hint that Google gave the responsibility for the retries to the developers.
I'm not sure what your looking for as an answer. The correct way is to implement an exponential backoff as mentioned in the docs. Depending on your use-case, different strategies can be implemented.
e.g. forced subscription -- like a general topic, that runs every app start is easy. One-off subscriptions, you might need some verifications i.e. a way to check if the user actually finished subscribing, retry if not.
I have a question regarding the firebase AUTH API. According to firebase you can perform 1000 requests per second / per project. I would like to know what happens if you exceed that limit and have, let's say 2000 users logging in at the same time / second. Will the 1000+ users receive an error? Or will they be queued to the next available slot? The documentation does not say that.
We are on the blaze plan btw.
Thank you for your help!
When we are talking about individual private push notifications per user (rather than per device), there are couple of ways to send them via Firebase:
Collect registration tokens, associate them with the user on the trusted server and send notifications to all registered tokens.
Assign a topic per user, e.g. topics/user-id and let the app subscribe to it upon successful login / unsubscribe on logout.
However, Firebase documentation recommends to use approach no. 1, saying "For fast, secure delivery to single devices or small groups of devices, target messages to registration tokens, not topics."
One concern is the latency (referring to "fast") issue. Is it really that significant in practice comparing registration tokens vs topics-based messaging?
More serious concern is security.
What does Firebase documentation mean exactly by "... secure delivery..." as opposed to topics?
In our case one device will likely be used by multiple users logging in and out. That means registration tokens will have to be disassociated from the user in the backend when user logs out. If something goes wrong and registration token is not disassociated, device will continue getting previous person's notifications.
Is this the trade-off I have to accept or am I missing some other option?
There are a few questions in there. Let's see if I can cover them main ones.
If you need to deliver messages to multiple tokens, the two approaches you're considering are:
Subscribe the app installs/tokens to a specific topic, that you then deliver the message to.
Keep your own registry of tokens for the user, and do the fan-out of user-to-tokens in your own code.
The biggest difference is in where the fan-out of a user to their tokens happens. When you use topics it is done by Firebase on Google's servers, while in the second case you do it yourself. There is no guaranteed performance difference between these two, but in the latter case you have more control. So you spend more effort (writing your own code for something Firebase can do for you), and in turn gain more control (which may or may not translate into better performance)..
The second question is around the security of topics. The documentation contains that note because topics often have a much simpler structure than tokens. For example, if you have a topic-per-user, you will often use the UID as the topic ID. And since you may be sharing that UID in other places, it is possible that other users may know a user's UID. And since subscribing to a topic only requires that you know your own token and the topic ID, that means that any user can subscribe to another user's topic.
I am using google cloud pub/sub for receiving the push notifications of any gmail user by setting a watch on the concerned users mailbox. I am able to do that. I am creating a one topic per user in my google console project and also creating one subscription per topic. As per my knowledge we cannot make more than 10,000 topics and subscriptions in one project(GCP). My question is that can we increase this limit. I want to increase it to 100k or 10 million. Is it possible. If yes kindly suggest some resources or references, where I can read about it.
At this time, the 10,000 topics and subscriptions limit cannot be increased. It is a dimension we'd like to scale up at some point, but for now, this is not a quota for which one can request an increase.
I'm trying to find out if there are any limitations for the topic names for FCM. Managed to find info about the number of topics (no limitations), but nothing like length of topic name or allowed characters.
Yes, not all characters are allowed, having space between words is not allowed in topic names.
From the docs:
sending messages to a Firebase Cloud Messaging topic is very similar to sending messages to an individual device or to a user group. The app server sets the topic key in the message body with a value like yourTopic. Developers can choose any topic name that matches the regular expression: "[a-zA-Z0-9-_.~%]+"
for more info check this: https://firebase.google.com/docs/cloud-messaging/android/topic-messaging (build request section)
Topic messaging supports unlimited subscriptions for each topic. However, FCM enforces limits in these areas:
One app instance can be subscribed to no more than 2000 topics.
If you are using batch import to subscribe app instances, each request is limited to 1000 app instances.
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.
Yes there are limitations on FCM topic names.
FCM topic must match the following regular expression: [a-zA-Z0-9-_.~%]{1,900}.