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}.
Related
As per the official documentation of AsyncAPI Specification to define event-driven APIs, there would be the need to define the basic components like info, server, channel, message, schema section using the specifications.
This is good enough for most use cases where messages are sent to the broker and consumed by one subscriber.
In case of AWS SNS, the message sent to the SNS topic will be consumed by many consumers as per the filtering criteria given during the subscription of the SNS topic.
How to define all those filtering criteria using the AsyncAPI Specification? Do we need to specify all the different possible examples of message payload to map each consumers specific payloads? Or is there any other better way to define this routing by SNS topic?
There is a pull request for these bindings. I suggest that you add your requirements and questions there - https://github.com/asyncapi/bindings/pull/84
I am using FCM console to send push messages to the users. Until now I am targetting using User Segments through which I can filter users based on language. But now I need to allow users to subscribe or unsubscribe to the type of alerts they can receive. So I am exploring the option Topics. But now from firebase console I can either target users based on User Segments or Topics.
I want to be able to use Topics with the options I can get in User Segments(where I can filter based on language). Is there a way to make this possible?
Thanks,
Sindhu
Segments can't be targeted with topics. Segments are populated by data collected by Firebase Analytics, and don't identify individual devices. Topics are just names that you make up, and the names must match between the device and server.
You will need to find a way to match up users in a segment to the topic that you create for that segment. You could try to use Remote Config to give clients the name of a topic that matches their segment, then use FCM to subscribe to that 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'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.
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.