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

In general, we at Voximplant are engaged in voice automation. Accepting a call from a cell phone, launching a client JavaScript script - there are a couple of thousand lines of logic on what to do with this call, including outgoing to web browsers and mobile applications - that’s the whole story. Another story is a 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 crash when they don’t like the WebRTC SDP package received on the other hand, and we wean them from this.

But, as it turned out, there are few voices and videos for customers: “We don’t want to write a chat ourselves, we have already copied everything twice and three pythonists quit. Give us a stack of unified communications so that everything is on the same platform and we don't steam. ” And last week we became that very “Unified Communications”. Now we can collect “Skype for Web” as a whole: 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, get feedback from you - how good the API turned out and can everything be done with it?

How we organized the API

A good API should allow you to quickly collect an analogue of Skype / Telegram, give an answer to the question “What happens if the device logs in after a month, and there are a million messages?” and have some kind of mechanism to hide this million messages somewhere when you close the application, and then quickly show it. 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. Using Conversation, you can send a message to the user, do group chat or an analogue of “channels” in Telegram. Conversations are created using the createConversation method (by the time the SDK method is called, you need to connect Voximplant to the cloud and log in):


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

In the same way, sending messages is organized: the Conversation object has a sendMessage method and the ability to subscribe to the SendMessage event , which will come to all participants of this Conversation, including the sender:


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

What if the user is offline?

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

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

Built-in caching

The user expects the launched messenger to start quickly and quickly show channels and messages. In order not to request messages from the server at each start of a web or mobile application, they can and should be stored locally with Conversations. To do this, we provided an API for caching: Conversation and Message objects have toCache methods, 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 there for now:

• HTTP APIs and hooks to make complex decisions. Using the current API, you can make an analogue of “Skype for Web” or Telegram without bots, where everything revolves around users and their messages. But to do something like “Zhivosayte”, where visitors can communicate with operators on the site’s pages, is now much more difficult: you will have to use one account for the site, one account for all operators and coordinate the creation of many conversations through your own backend.
• Listen carefully to early adopters' feedback and make changes that make using the API better. Join up to 1000 users for free!