Geekly Articles each Day
📜 ⬆️ ⬇️

We could not resist and also made an SDK for messengers: Web, Android and iOS


In general, we are engaged in voice automation in Voximplant. Taking a call from a cell phone, launching a JavaScript client script — there are a couple of thousand lines of logic to do with this call, including outgoing to web browsers and mobile applications — this is the whole story. Separate story - video. Education, telemedicine, meetings. The same SIP, the same codecs, only data is transmitted a hundred times more. At the same time, browsers like to hang and fall, when they do not like the package received from the other side of WebRTC SDP, and we wean them off.

But, as it turned out, there were few voices and videos for clients: “We don’t want to write the chat ourselves, we’ve already copied everything twice and three Pythonists quit. Give us a stack of unified communications, so that everything is on one platform, and we are not steamed ”. And last week we became this very “Unified Communications”. Now we can put together “Skype for Web” entirely: not only voice and video calls, but also messaging. Under the cut, I want to show how the messaging we have done works and, I hope, to get feedback from you - how good was the API and did everything possible with it?

How we organized the API


A good API should allow you to quickly build an analogue of Skype / Telegram, answer the question “What will happen if the device logged in a month and there are a million messages?” And have some mechanisms to hide this million messages somewhere when you close the application, and then quickly show. Plus it would be great if the user could connect from different devices and somehow live with it.

Our API is built around “Conversation” objects that collect users and messages in one place. With the help of Conversation, you can send a message to the user, make a group chat or an analogue of the “channels” in Telegram. Conversations are created using the createConversation method (by the time the SDK method is called, you need to connect to the Voximplant cloud and log in):
')
const msg = VoxImplant.getMessenger();
msg.createConversation([
{userId: 'user1@myapp.myacc'},
{userId: 'user2@myapp.myacc'},
]);
// 'VoxImplant.Messaging.MessengerEvents.CreateConversation' constant
// can also be used. The event will be triggered for all users listed
// as conversation participants.
msg.on('CreateConversation', e => {
// Use 'e.conversation' object to send and receive messages.
});
view raw example.js hosted with ❤ by GitHub

All users who are listed in the list of participants will receive the Event CreateConversation , to which you want to subscribe . The user who created the Conversation will receive exactly the same event. That is, the createConversation method returns nothing: the SDK communicates with the server, a Conversation is created there, its description is sent to all connected SDKs that are logged in with the participants of this onversation, and an event comes to these SDKs.

Similarly, the sending of messages is organized: in the object Conversation there is a method sendMessage and the ability to subscribe to the SendMessage event that will come to all participants of this Conversation, including the sender:

msg.on('CreateConversation', e => {
e.conversation.sendMessage("foo");
});
msg.on('SendMessage', e => {
console.log(e.message.text);
});
view raw example.js hosted with ❤ by GitHub

Notice that the createConversation call creates a new object each time. In practice, when exchanging messages between two users, we want each time it to be the same object with the entire message history. For this behavior, we have a distinct flag: if you set it for onversation, then a repeated attempt to create distinct conversation with the same set of participants and their flags will return the id already created.

What if the user is offline?


Have you ever seen what happens with Skype mobile when it is launched on a new device after a long interruption in use? The poor application simply tears apart the number of events, and it takes a long time to think about how to display this.

To solve this problem, we sequentially number all the events for onversation that come to the user. If the user was offline, then returned to the online server will not try to send him all five thousand events that happened during the absence. Instead, the client itself receives the current list of its onversation (new ones may appear) with the help of getUser , and then for each onversation compares the saved and received from the lastSeq server. If the values ​​diverge, you can safely call retransmitEvents and receive events that happened while the client was offline. The method accepts a range of sequence, which allows in case of a particularly large number of them (launching the client on a new device) to take them in small portions. The same sequence is used to track the number of unread messages.

Built-in caching


The user expects that the launched instant messenger starts quickly and quickly shows the channels and messages. So that every time you launch a web or mobile application, you do not request messages from the server, you can and must store them together with Conversations locally. To do this, we have provided an API for caching: Conversation and Message objects have methods toCache, and the Messenger object allows you to restore them from the cache using createConversationFromCache and createMessageFromCache .

Future plans


This is the first version of the Messaging API and its further development depends on what our users want. What ideas are on now:

Source: https://habr.com/ru/post/336038/

More articles:


All Articles