i'm about to create a chatroom, for each two users like to exchange messages i like to create a Kafka producer and Kafka Listener with a specific Topic to to them
You are describing Topic per entity here. You could do that, but you shouldn't. Each topic will be a directory on the drive, and some open file handles. You would run out of open file handles if you are getting a lot of rooms.
You could create a "Chatrooms" topic with a number of partitions and have your chatrooms have unique id's. A listener would skip all messages not meant for that particular chatroom.
Related
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.
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.
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.
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.
The Firebase chat application seems to suggest that all clients will receive the messages sent to a given FireBase url.
Now, one way of ensuring that users only receive messages sent to a specific channel is to filter messages at the client, but this would mean that all messages will be propagated to all clients and the client would do the filtering.
Is there any way to establish channels at the Firebase server - or does this mean that one would need to create separate firebases for separate channels, which would mean that if one wanted user-specific push-messages, it might require creating one channel/firebase for each user.
So, what is the suggested solution?
The Firebase Data Structure makes this quite easy, actually! The demo app puts the chat messages in the root of the Firebase (i.e. https://samplechat.firebaseio.com/), but you could just as easily use separate locations within your Firebase for separate chats, e.g. /chat1, /chat2, etc. Or better yet, you could have a /chats/ location with an arbitrary number of chats underneath, each named uniquely (possibly using push()).
Then a user could receive and push messages to a particular chat by referencing it directly (e.g. https://samplechat.firebaseio.com/chats/chat-id/) and then they won't get any data for any other chats.