What to do when entities keeps changing in Azure Search? - azure

I'm working on a chat-like application and would like to provide search capability for it. I was thinking of using Azure search. Once possibility is to consider each chat room as a single entity in the Azure search so that each entity represents a single chat room. The challenge I encounter is because each chat room keeps receiving new messages, the index for a chat room keeps changing. I can use a queue mechanism to queue up the changes and update my entities in the Azure Search but I don't know whether it is a good and scalable solution. Obviously I need to increase the number of replicas to keep up with the changes. Any recommendation? Is Azure search a suitable tool for such a scenario?

H.Z.,
We do have customers that use us for Chat / Instant Message based applications, so we might be viable for your needs. Before I answer your questions, can you tell me what types of things you would want to be able to search?
Is it merely to search the chat rooms or is it to search both chat rooms as well as the messages within these chat rooms? If it is just to search the chat rooms, you might want to consider going your suggested approach and then store the chat messages in a lower cost store (such as Azure Storage) and then simply pull in the message text as needed.
If it is the latter, then the next question would be whether you want to be able to do a search that spans both chat rooms and the messages within them which would indicate that it makes a lot of sense to have them within a single index, although whether you put all messages in a single document or have one document per message we should drill into a bit more. The main issue I would think of with having all messages in one index is in the case where a user wants to drill into (or filter) specific messages within a chat room. I am thinking this might be a little harder then if you split messages into separate documents.
Another option might be to have 2 indexes. One that has the chat rooms and then another that has the individual messages within them.
In any case, I hope that helps as a start and based on your responses hopefully I can help you drill into the details more.
Liam

Related

Real-time notification feature in MERN stack

I am trying to build a web app where users can receive notifications if their posts get likes. This functionality is actually working but the notification component renders only when the page reloads. But I want it to re-render the notification component as soon as there is a change that occurs with it. I am trying to make this work with SocketIO both in client and server but it feels like there should be a way easier way to solve this issue. How?
One way to achieve this is to use server-sent events (SSE), which can be seen as a uni-directional
and simplified version of WebSocket (only server can send data to clients). You might need route param or query string so that users can connect to different channels.
If it doesn't have to be so real-time (i.e. receiving notifications 1 minute after somebody liked the post is okay), you could also try (long)polling.
However, since post-like table may contain a huge amount of data, constantly querying it is expected to result in bad performance on the server. Also, adding an extra column to mark if the user has been notified about a specific like is trivial.
A possible workaround might be to create a new table, say pending-like-notification, which is used to stored all pending like notifications. Whenever a post is liked, we insert a new record into this table.
Therefore, when a user tries to query if any of his posts is liked recently, in the backend we lookup this table instead of the post-like table, and delete the selected rows after the user has been notified so that the amount of data in this table can stay low (hopefully).
All in all, in this scenario, I think SSE and WebSocket will be better choices.

NodeJS and Socket.io creating room with two users

I'm doing chat app and I want to do it real time. Chat will be for now between two users. When user access to chat it finds all messages between them and displays messages. I think I need to create room with two users and then store room id in database. But I'm new to socket.io and I need advice how to do it.
Try to take some already pretty wide used chat, like Slack, as example. Usually you need pretty same set of things, workplaces, channels, private messages (like room but for two users only), and have users sending text messages with some formatting or images or just any files. Just take it easy, plan and make it step by step.
Also take note, that for both parties have their chat view updated with new messages you need not only save message one user send to db, but also broadcast that message to everyone, involved in conversation.

Track multiple context for the same Bot

We have a bot that will be used by different customers and depending on their database, sector of activity we're gonna have different answers from the bot and inputs from users. Intents etc will be the same for now we don't plan to make a custom bot for each customer.
What would be the best way to separate data per customer within Chatbase?
I'm not sure if we should use
A new API key for each customer (Do we have a limitation then?)
Differentiate them by the platform filter (seems to not be appropriated)
Differentiate them by the version filter (same it would feel a bit weird to me)
Using Custom Event, not sure how though
Example, in Dialogflow we pass the customer name/id as a context parameter.
Thank you for your question. You listed the two workarounds I would suggest, I will detail the pros/cons:
New API Key for each customer: Could become unwieldy to have to change bots everytime you want to look at a different users' metrics. You should also create a general api (bot) where you send all messages in order to get the aggregate metrics. This would mean making two api calls per message.
Differentiate by version filter: This would be the preferred method, however it could lengthen load times for your reports as your number of users grows. The advantage would be that all of your metrics are in one place, and they will be aggregated while only having to send one api call per message.

Socket.io: Live Chat Design, better way to initialize list of rooms and people?

I am trying to create a meeting app using socket and node. So far, following this tutorial (https://scotch.io/tutorials/a-realtime-room-chat-app-using-node-webkit-socket-io-and-mean) I see that they are making the list of available users to chat using Mongo.
My meeting app consists of available rooms and people (so there are list of rooms available and list of people that is inside a room, or not anywhere in the room, you cannot chat with people that is not in a room yet). Is it better if I make the list of rooms and people in just a variable and not on database (and is it possible that new people joining have access to that variable)? And if indeed using variable, how many concurrent user connection that can connect at same time, like should I allow only 1000 users connect at same time if I'm using variable method?
I suggest you continue to use MongoDB. You would not actually store the connections though. You would want to store the room IDs (along with their name, description, etc.) and user IDs. In the Users collection, you would also store their name, bio, online/offline status, etc. Either you build a new document every time a new user connects, or you implement some sort of authentication system so users can login in from multiple sources.
If you use MongoDB, you really don't have to worry about having too many people online. It can handle whatever you give it.

sending notifications to selected multiple users

In my app I have a user hierarchy in form of a tree of users
A user can send a notification to all its subordinates, including indirect.
What is the best way to achieve this with Azure Notification Hub?
I see I can choose between either registration management from device or from backend.
Leaving aside the security, I don't see too much of a difference for my scenario. I guess the tag is the user id.
If 100 users need to receive a notification, I need to call 100 times to send the notification.
Is there a better way?
Yes, in general you are right - call 100 times. Do not use 'tag1 || tag2 ...' expression to reduce number of calls because it was originally designed for broadcast.
But for the particular case it is often possible to figure out much better way to implement the things based on some limitations (number of users, max hierarchy depth etc...) and other factors. So you could describe you application in more detailed way right here or contact Microsoft support or just email me directly or we even could setup phone or Skype meeting. What does work best for you?

Resources