I am using Open Messaging and I have made a user application that is working fine.
Now, I need to make an agent widget that is embedded into another web page. Everything is working as expected, except;
When I subscribe to the agent notifications with v2.users.${userMe.id}.conversations.messages notifications channel, I get the notification of the message but it is a large object with just participants and then message ID's that I can then use conversationsApi.getConversationsMessageMessage(pcConversationId, message.messageId); to get the message.
Unfortunately, this is really heavy, is there a way to get notifications for messages more efficiently? The additional problem of using getConversationsMessageMessage is that if the user spams the chat then I quickly start getting 429 errors due to API limits.
I've been digging through the docs but I can't seem to find anything specific about it.
It might be beneficial to look at your overall API requests and agent widget design, and make sure there isn't room for more efficient calls elsewhere too. At the maximum supported limits, you would be looking at 30 inbound open messages and 30 outbound (agent) messages a min, per conversation. So that would be 60 GET message, api calls a min against your agent's token. That should still be well below any api rate limit for that user. Also, it's almost impossible this is a real world scenario, agent's can't read messages that fast, or type thoughtful replies that fast either.
Yea I've reversed how the Genesys front end does it, looks like it aggregates the message ID's and then does a "bulk" API request. I'll do some queuing and use that endpoint and see if that helps.
I'd be curious to know the reason the message isn't sent down the WebSocket, I'm assuming to avoid large attachments slowing comms?
Yeah batching them up, then using the bulk api there is a good solution to limit api requests too. I'd still suggest doing some lazy loading on your agent widget, for large message conversations as well.
There were originally several reasons behind the full message content not being in the websocket. Large, and constantly expanding, content bodies were definitely one of the reasons. Limiting the places to store/expose the message details were another.
