I am creating a service (accessible via web and app) where users belong to a team. Whenever a user does something, all the other online users (*) in his/her team must be notified. I am evaluating RabbitMQ for this.
(*) Note that it is possible that the same user has multiple sessions at the same time: he could be logged in in different browsers at the same time, or more likely in the browser and and app at the same time.
My current approach is to create a topic exchange for each team:
When a user logs in, an auto-delete queue is created and bound to the exchange of his/her team.
When a user did an update, the backend sends a message to the exchange of the corresponding team.
Finally, all active queues - that is, all active sessions - receive the update message.
This is great, because the update message must only be sent once by the backend. However, the problem here is that the initiator also receives his own update. I would like to avoid that. Is that possible? Or should I have another design?
Ofcourse, I can always add the user identifier of the initiator in the payload of the update message and filter on that field when receiving an update message, but the message is still received.
That is an interesting question. After thinking about this for a while with this particular design, when the user wants to get the update and also make some changes while others should know about it I feel like you need to think of some other design.
With Topic as an Exchange you will always get the notification as the queue is created when you logged into the system. And Topic will broadcast it.
The topic is more for a subscription kind of thing where you can not specify easily where you want to skip one subscription or not.
One design I can think of which is bit complicated is as follow:
Create one Topic Exchange per person in the team.
When another User logs in he will subscribe to the Exchange of all other team members.
When a user makes an update it is sent to his own Exchange where all others are listening.
That way the user will not get his own update as he is listening to others topics.
Related
I am developing an app where I want to send notifications to multiple users from my backend server. These notifications will contain 4 different contents, three of them will go to 3 different users, but the forth one will go to more than 1000 users, the frequency of theses messages will be 3 to 7 times a week. Is it ok to send this amount of messages one by one using the Cloud Messaging api? Or should I group the messages before sending?
I thought about creating a topic in the Cloud Messaging, and subscribe the users to it and then send a message, but I don't if it is correct to keep subscribing/unsubscribing users just to send one message.
NOTE: I've never used any push notifications service before.
The Firebase Cloud Messaging infrastructure delivers billions of messages per day. The volume you're describing sounds well within reason for it.
Without knowing more about the use-case it's hard to say whether using a topic would be a better approach, so I recommend reading the documentation on topic messages to get a better understanding for it.
I have successfully set up a DM bot with the Account Activity API. Everything works very well, except that sometimes the message sent to the bot (through the Twitter's web interface or mobile application) doesn’t fire a webhook to my server. The messages could be quick replies responses or plain text.
The reason is obviously not a downtime of my server since I tried to make a conversation between 2 webhook registered users (so my server receive the webhooks for both users) and for the same message sent, I have successfully received the webhook of the sender (the user) but not for the recipient (the bot).
As the bot isn’t in production yet, the reason is not an overload of messages. There is currently only 2 users that make conversations. From my experience, around 10% of messages are "lost".
I'm using the free (sandbox) Account Activity API tier, but as I understand the only differences between the free and paid versions are a higher number of subscriptions (I'm fine with 15) and the “Retries” feature. Regarding this feature, it is specified that “The Account Activity API provides a retry feature when the client’s web app does not return a ‘success’ 200 response for an account activity webhook event.”
It clearly states that the event failure concerns the client’s side, not the Twitter side. Considering this issue (my server doesn't receive the webhook at all), there is no guarantee that every event will be delivered even if in a paid plan.
This is a big inconvenience for bots since a button can only be clicked once, so the user must retry the conversation from the beginning (besides the fact that the bot "doesn't work"...)
So my questions are :
Is anyone here experience this issue ?
Is this a “bug or a feature” of the free Account Activity API ? I mean, at random the free tier doesn't fire the webhook on purpose (even if it's not specified in the docs) ?
Is there a way to see or measure the webhook failures Twitter side, via the dashboard for instance ?
A guess is that the events could be more accurate if the account is verified (with a blue badge) or hit a followers number threshold ? The treatment could be different due to the potential surge of events, so they are monitored with more ressources, thus more reliable ?
I already create a topic in the official Twitter forum and there is at least one other person in the same case, but no official answer from Twitter so far.
Thanks a lot !
BR,
Simon
I've got an official answer from Twitter :
Unfortunately it is not possible to achieve 100% delivery rate when there is only 1 delivery attempt for an event, which is why we have retries (and even then, retries are not a guarantee either). Things can go wrong; maybe internal issues in Twitter Data Centers, routing issues in the internet, hosting issues at your webhook, etc.
So from the time being, it seems that there's not way to have a 100% success delivery when you build a bot on Twitter.
Full answer can be read here.
We are building an internal bot to monitor / control our software. It is NOT exposed to the public and will be used by other team members, either directly (as a direct chat) or through a few channels depending which side of the software is on topic.
The bot should do two things:
reply to commands; the reply should go to the user that originated it.
send notices to all users / channels it is involved in.
When a message arrives, I can get the channel id and the user id; while the user id is kind of guaranteed to exist for while, what is the situation with the channel?
Can I store the channel id and broadcast messages to all channels the bot is involved in? what happens if a channel is closed? do channel ids have lifetimes?
I can't really find anything online about the best practice regarding this scenario.
I have doubt Understand what you want but it seems better know these things :
ID's are unique in Telegram and even in all others applications so
they are lifetime
Channel ID , Groups ID , User ID have same behavior but their difference is on their integer. (User ID's are Positive but channels and groups are Negative. check example here)
Users can just send message in channels that they have admin permission in it right? Bots are same. so if your bot isn't admin anymore , the Telegram gives you error in response and you can check it and after facing that error delete that channel ID in your channels list.
I hope this information help you but if you have any other question feel free to leave a comment and I'll update the post and answer you immediately.
how to send Send message to the all of bots users?
There is no way to sned message to all ?
what is the method name ?
From Official API FAQ:
How can I message all of my bot's subscribers at once?
Unfortunately, at this moment we don't have methods for sending bulk messages, e.g. notifications. We may add something along these lines in the future. (...)
Obviously, if you store users chat_id, you can send individual message to all users (I use this method).
Navid wants to send message to all subscribers via bot.
If subscribers are more than 100 persons bot will very slow to sending all messages and may doesn't send messages to all.
Navid's question was how we can send message without this problem?
you can send with curl_multi_exec
Currently, a developer would need to implement a special broadcasting function that would send the message to each active user at the time adding a small delay to avoid hitting the rate limit of 30 messages per second (see https://core.telegram.org/bots/faq#how-can-i-message-all-of-my-bot-39s-subscribers-at-once). This would mean that a very popular bot with say 10K active users cannot give timely notification as the last user would get the message about 5 minutes after the first user.
Here is a feature request to ask to add a method in the Bot API to broadcast a message to all its active users at once. You can upvote this feature request. https://bugs.telegram.org/c/8463
Is it possible to get MailChimp or Mandrill to notify a webhook URL whenever a message is either created for a list, or scheduled to be sent, along with the list and message IDs?
I have a client that wants to intercept messages from his campaign, add special data from his server, then send the resulting template through his connected Mandrill account. I'm trying to figure out how to implement the first step in this process.
Although I know this is old someone may stumble into this thread, have you checked out the webhook information?
http://help.mandrill.com/entries/58303976-Message-Event-Webhook-format
It has an easy way to implement it inside the account. You just setup a URL to intercept and parse the incoming data. I recommend first saving the data then using a scheduled task to parse the job separately so you don't lose data (although mandrill will try 100x).
If the unique id is not enough for you with your events, and you are concerned about specific campaigns you can tag the emails upon send and they will have the tagged information with the incoming event.