What happens to SNS topic subscriptions that have been confirmed and then abandoned and not explicitly unsubscribed? Is there some expiration time that can be set? I didn't see anything about this in the documentation. It's possible that I could collected a lot of garbage subscriptions for the topic if I have a lot of abandoned clients.
You may be wondering why I'd ask such as question.
I'm wondering about this as I'm working on something that requires publish-subscribe behavior and I could have dangling subscriptions that I would like to manage. It could be a large number of dangling subscriptions - like thousands. I don't control the client code so I can't guarantee that they will be well-behaved and they may just "disappear" from the network and never get a chance to unsubscribe even if they were well-behaved.
Is there some best-practice hygiene for this?
I could periodically schwack all the existing subscriptions (as the topic owner) and the clients listening to topic traffic would have to resubscribe from time to time, but that is not a good path IMHO. It would leave perhaps critical gaps in topic traffic to legitimate listeners and also levy a "re-subscribe" requirement on them I would prefer not to.
Maybe I'm just being dumb. Any help is greatly appreciated.
There really is no auto unsubscribe option once you subscribe. The best way is to maintain the list of topics that you are interested in at any time. If Any other topic outside that list sends you a notification then just unsubscribe to that topic with the unsubscribe url provided in the request sent to you.
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.
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.
I am looking for a product to solve a particular task and I'm having a hard time sorting out which product or type of product can accomplish the task. I am looking for something to handle POSTing notifications via HTTPS.
One of my use cases is a mechanical turk type scenario. A client will request a task be started via an API call. A human will get this request do the task, tell the system the task is complete, and the system will send a HTTPS POST to a subscriber. So it's a long-running async request.
I am looking for something that will take care of making this POST for me. I would like something that is reliable and durable. Of course I can write the POST myself, but all of the other niceties that come with a queuing application would be nice to have (and I don't wish to implement all that myself).
I have been looking at a number of queuing, MOM, and ESB products. From what I can tell the queuing products don't seem to push notify over HTTPS and the MOM and ESB are a little too heavy handed I think. For example I think BizTalk will do what I need but that has a lot of overhead. The one solution I did find was Amazon's Simple Notification Service, but that appears to only send from the amazon.com domain, but I want the messages to be sent from my domain.
Can anyone help identify a product that will help? Maybe I'm just overlooking something, not sure what I am looking for, or have to choose a different way of implementing this.
The answer I was looking for was webhooks. Here's a great presentation on what they are and how they can be utilized.
if you want a serverless way to do webhooks, check out IronWorker's webhook support, here's an article on it: http://blog.iron.io/2012/04/one-webhook-to-rule-them-all-one-url.html
nginx has a messaging module that may be just what you need.