The challenge is to create a live chat room that allows 100 (+) people to simultaneously chat in one chat room at the same time with all the messages coming in real time.
The performance issue I am facing and want to find a solution for is that when I add a new “Message” to the “Chatroom” it takes 3 seconds for the “Message” to be uploaded to the database and display in the repeating group I am using.
What I think is the issue:
The repeating group setup I am using is filtering all the messages at once and ordering them in descending order which is causing the delay as this operation is happening every time a user adds a “Message”. The filter is also grabbing ALL of the “Message” data objects (which is bad because as the number of message objects grows, the query time will increase proportionally).
The objective here is to create a very fast, lag-free live chat system on Bubble.
Some ideas:
Utilize JSON / JavaScript filtering on client-side?
(not sure the exact query for this) But, only show the most recent 20 messages in the repeating group.
Have two chatroom objects that hold messages, one called “ArchivedChatroom” and “Chatroom”. Creating a backend workflow that checks if “Chatroom” contains more than 20 messages, if so, move messages greater than the most recent 20 messages into “ArchivedChatroom” as to always keep “Chatroom” with ever only 20 messages (to prevent the query time from increasing proportionally). I do not know how to create the backend workflow that is able to recognize when “Chatroom”.count() contains more than 20 objects though.
Thank you loulouaying1204 for that idea. The only issue with that is that we want to keep the database on Bubble as we already have user accounts configured and the database built out already on Bubble – If there was some way to store the messages created on backendless rtc message web socket in Bubble’s databases (so that we only have 1 database) that would be ideal.
I may be wrong/may be misunderstanding your solution. If so, please let me know.
How are you handling the filtering? Is your filter client side (":filter") or server side (stuff in the “Search for” box). If the latter, you shouldn’t have scaling issues. If your filter is server side and your message datatype is lightweight, then it shouldn’t be slow.
Also how have you set up the data structure? I think it will be fastest if the Message datatype has a field that connects each Message to a specific Chat, rather than a Chat datatype containing a list field holding all Messages.
When I click “Send”, it takes about 3-4 seconds before the message appears in the repeating group. I think there is a better way to do the filtering, although, I am not sure where to enter an example filter like “only grab the most recent 20 messages”.
In your RG search, wouldn’t you also need a constraint that limits the messages to only those for a specific Chatroom?
In the RG itself, are you only downloading LiveChatMessage fields, or are you pulling any fields from other datatypes?
What does your workflow look like? Just to ensure that the issue is in the RG filter/display, and not the workflow itself.
Are you using any third-party plugins anywhere in this process?
Yes, try a fixed repeating group of the first 20 items and see if that has any impact. A scrolling RG is supposed to be similarly efficient, but it’s worth doing this check.
I don’t have a chatroom in my app… but I do have a fairly complicated and data heavy database, and my time from creation to appearance in the data list much faster than 3 seconds.
*** In your RG search, wouldn’t you also need a constraint that limits the messages to only those for a specific Chatroom?**
The objective here is to try and create only one public chatroom, so it needs to get all messages associated with that one chatroom.
*** In the RG itself, are you only downloading LiveChatMessage fields, or are you pulling any fields from other datatypes?**
Only LiveChatMessage fields. The LiveChatMessage does have a field for User. This may be causing issues if when querying it is also pulling the user’s data with the message (although this field is built in and I don’t know how to remove it; it would be better to set the User to an id so that it doesn’t do another query).
*** What does your workflow look like? Just to ensure that the issue is in the RG filter/display, and not the workflow itself.**
Workflow (the one adding the new message to the database is the “When Button is Clicked > Send to backend…; backend workflows shown below. The other two workflows are for scrolling to the most recent chat message when a new message is added.”).
*** Are you using any third-party plugins anywhere in this process?**
No third party plugins are used for the live chat that I am aware of.
*** Yes, try a fixed repeating group of the first 20 items and see if that has any impact. A scrolling RG is supposed to be similarly efficient, but it’s worth doing this check.**
Do you by chance know the query to grab the most recent 20 messages? I am not sure which one to use. The messages in the RG go from oldest-newest, and we want the most recent 20 messages.
Hi, first try moving the create new message workflow to the front end and see the impact. This type of workflow should be faster as a regular, not backend workflow.
To limit items to 20, you can change the RG to fixed number of rows, rather than a scrolling RG. But I don’t think that’s the issue, since the scrolling RG you have should be pretty efficient.
Also, if all messages are collected together into one chat, what’s the reason behind having a “Chatroom” datatype?
This sounds like it could be the same issue as reported here. In my case I’m seeing a ~3 second delay on making any changes that originate inside a repeating group. This is a new behaviour for me, previously the update was instant. Just to check, do you get the same behaviour if you Create / Edit the Thing from client side?
I have filed a bug report. If you think this could be the same it would be great if you could too.
I have built a couple of chat windows but admittedly not with performance in mind. However, in some instances rather than use records for each message, my method has been to use one text field as the entire message stream. If you append each new message to the start of the text field then you get the appearance of a chat stream.
This removes any record based interactions and the persistence of the single field maintains a reasonable update speed without having to do a refresh of any sort.
You could use a backend workflow to keep incoming messages separated if needed (I’ve never needed to do that). You can even stick time and user stamps on each message. I know it’s a hack but when I’ve needed it, this has worked well in simplified circumstances. It might not work for you.
