I'm trying to implement push messages for a really big amount of users. I guess that topics is a pretty good fit for this scenario. Anyway, there are a few questions I cannot still resolve:
How can I know which topics are invalid / expired when sending a push message to a topic? (think on more than 1M of tokens related)
Is there a way for getting the amount of relations for a topic? I could keep the tokens on DB and make this aggregation by myself, but I'm wondering if there is any other option by using any method of the public API
How can I know which topics are invalid / expired when sending a push message to a topic? (think on more than 1M of tokens related)
There is currently no way to check if a topic is invalid/expired. A topic doesn't even auto-invalidate/expire. A topic ceases to exist if there are no more subscribers to it, but sending a message to a topic (a valid topic name), regardless if there is a subscriber or not would not return an error that lets you know if it doesn't exist.
Is there a way for getting the amount of relations for a topic?
There is currently no API that handles this. It is the developer's responsibility to keep track of this data (in your case, the number of subscribed) when they need it.
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.
Seems like majority of solutions here require the developer to manually save each user's push token in addition to Firebase saving these tokens as well, then iterate through these and send out notifications. This is not really desirable since I would be storing push tokens in two separate places and need to make sure their lifecycle management is synchronized, which is error prone 😢Is there a better way?
Some options I considered:
Give each user a person/unique topic, then map out a geolocation per topic; then filter through these locations, aggregate these topics into batches of 500 and send a push. This is probably the best option so far 🤷♂️ but seems like a silly use of topics API.
Bucket users in cities, with each city corresponding to a topic; then find all cities near a location, and send a push to those topics. This is doable, but lots of complex city mapping code without much flexibility (vs. considering a simple radius).
Manually store push token → user → geolocation; filter out the ones you want, then send a push to the token specifically. This is problematic for many reasons (multiple device management, push token lifecycle management, data duplication, etc.)
Ideally, there is a way to send out a push notification to a list of user IDs, without even touching push tokens, is there a way to do this?
The only way to associate a device token to a user ID is to store that mapping yourself. You should also assume that one user could have multiple devices. FCM doesn't have a concept of a "user". It only knows device tokens. Your app has to bring the concept of a user, then map that to tokens in code.
Note that any messaging solution that requires topics is not "secure". Anyone can effectively receive messages from any topic.
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 sending fcm notifications.
Now I want to register user to multiple topics in one request, how can I achieve that?
I have read the documentation but I have not found any documentation for that?
Also what is the limit of number of topics for a single device after which it starts displaying TOO_MANY_TOPICS errors?
Usually there should be no limits for subscriptions and topics (see https://firebase.google.com/docs/cloud-messaging/android/topic-messaging). I personally go with a foreach loop if there are 20-30 topics to send for one user.
There is no API to subscribe to multiple topics in one go. You'll have to call the API separately for each topic. As the documentation says, this call needs to be made from a server or otherwise trusted environment.
I'd take this approach up to a few dozen topics. If you need more than that, consider creating some broader topics. For example: many apps have a topic called all that they also send all messages to. That way people that want all messages, can subscribe to the all topic, instead of to each individual topic.
Having a tricky problem. I have firebase messaging, recording tokens in the database (as prescribed). Then I'm running triggers to send to topics (using functions). I noticed a bug when unsubscribing from a topic (had a space in the name - since fixed) , so the user didn't get to unsubscribe properly. Ever since they are getting that topic. Just wondering if theres a way of deleting old tokens / expiring - then unsubscribing from all topics. Basically I'm looking to create a "reset" button of sorts incase this ever happens again.
I had the same issue on my profile. However my cure (and test) was to delete and recreate my profile. Not an ideal solution! Everything worked great again after that.
Basically I'm looking to create a "reset" button of sorts incase this ever happens again.
Currently you cannot do that, topics are based on publish/subscribe model. Therefore the user who subscribes to a topic has to unsubscribe using his own phone to stop receiving notifications related to that topic.
If you created a topic by accident and all users unsubscribe from it, then it is no longer a topic and no one will be able to subscribe to it or receive any notification related to it.