Before we begin, let’s look at a piece of Javascript pseudocode.

// Join a chat room, Imclient.shared. join(roomId, (isSuccess, Error) => {if(isSuccess) {// Join RTC Room to obtain audio streams and publish audio streams rtcclient.shared. join(roomId, role, (isSuccess, Error) = > {// Determine user behavior according to role, Subscribe to the audio stream or released audio stream if (role = = on) {RTCClient. SubscribeStreams (streams, (error) => {})} else {RTCClient.publishStreams(streams, (error) => {})}})} else {console.log(error)}})Copy the code

Conventional language chat room solution

The code above shows a common language room solution in the industry, which is the process of building a language room using IM and RTC capabilities. \

With this solution, developers need to address the following issues:

  • Maintain both IM and RTC rooms
  • You need to determine the subscription and publication of streams based on roles
  • Different error messages need to be handled

Now let’s take a look at the basic process of dealing with the common operations of the language chat room using a conventional solution.

(Basic process of loading wheat)

The logic developers need to deal with is as follows:

  • Stores the mic bit information
  • After updating the mic information, synchronize the mic information of all users in the room
  • Release the audio stream on the MAC, cancel the release on the MAC
  • Switch the logic of subscription streams on or off the mic (if the role is the master, it needs to subscribe to other anchors; if the role is the audience, it needs to subscribe to the co-streaming of anchors)

The conclusion is that the development of a chat room based on the underlying SDK of the PaaS service is laborious and requires considerable business logic.

Language chat room solution evolution process

In fact, the above solutions are the second generation of language chat solutions, and also the mainstream solutions provided by various PaaS service manufacturers. \

Let’s take a brief look at the evolution of chat room solutions.

First of all, it needs to be clear that the core of language chat room is how to better manage the wheat.

The chat room solution goes through three stages.

The first generation, based on business server management mic bit: PaaS service providers provide back-end and front-end open source code, based on which developers carry out secondary development. That is, the front-end interface invokes the back-end interface through the Restful interface, and the service server maintains the synchronization and update of the mic bit information.

The second generation, based on the front-end + example project two open way: namely, the management of mic through the front-end IM SDK directly modify the chat room attributes to maintain and modify the mic information, without the participation of the business server, can be combined with the RTC SDK to achieve audio stream change and subscription. In addition, the manufacturer provides the corresponding open source code, according to which the developer can double open.

The third generation, which is the solution provided by Rongyun at present, organically combines various basic services according to different fusion scenarios (such as chat room, live broadcast, etc.), provides apis and callbacks close to business, and directly encapsulates them into specific scenario-based SDK.

We compare the advantages and disadvantages of each scheme from the three dimensions of learning difficulty, development difficulty and expansibility.

Learning difficulty

The first-generation solution is based on service servers to maintain and manage mic bit information. Developers need to handle complex logic such as multi-user mic bit synchronization and stream management. In addition, if you want to achieve a complete language chat room project from 0 to 1, you need to access and learn the open source code at the same time, which is very difficult.

The second generation solution directly calls the storage capacity of IM SDK based on the front end to manage the mic bit, which saves the process of managing the mic bit on the business server and is relatively simplified. However, developers still need to learn various capabilities of the underlying SDK.

The third generation solution, based on the second generation solution, encapsulates the basic capabilities into APIS close to business scenarios, enabling developers to quickly work without understanding the underlying implementation, but only the product concept, and develop complete language chat projects from 0 to 1.

The development of the difficulty

The first generation of solutions required access to both the front and back end of the code, which was extremely difficult to change.

Second-generation solutions require changes based on an understanding of the use of the underlying SDK, which is difficult to redevelop without deep knowledge.

The third generation solution only needs to understand the concept of the product, whether it is SDK based development, or sample based development, it is easy to grasp.

scalability

Due to the cost of learning and the difficulty of development, the development of the first generation of schemes was tied up, and it was difficult to expand new gameplay and modes.

The development difficulty and learning cost of the second generation scheme are reduced to a certain extent, and the expansibility is limited to the understanding of open source code.

The extensibility of the third generation solution depends on the degree of encapsulation whether the extensibility properties provided by the SDK are rich or not.

(Comparison of three generation solutions)

A sample demonstration of the third generation solution

Talk is cheap. Show me the code. Let’s take a look at some examples of why scenarioc-based SDKS are a better solution, directly pushing the industry into a new phase of development.

First, the user goes to the mic.

/// @param seatIndex Indicates the number of the seatIndex. // @param successBlock Indicates that the seatIndex is successfully added. // @param errorBlock Indicates that the seatIndex fails to be added (void)enterSeat:(NSUInteger)seatIndexsuccess:(RCVoiceRoomSuccessBlock)successBlockerror:(RCVoiceRoomErrorBlock)errorBloc k;Copy the code

This is rongyun chat room SDK package on the mai operation. Developers do not need to pay attention to the update and synchronization of the mic information, do not need to care about streaming subscriptions and publishing, just input the number of the number they want to access the mic, all the details are already implemented in the SDK.

Let’s take a look at the common application in the chat room scene, the general process is as follows:

(Application process)

The complicated mechanism of applying for and agreeing to loading wheat was simplified into two apis and one callback, which realized the complex mechanism of loading wheat succinct and efficiently.

  • RequestSeat is called by the user who wants to get on the MAC to send requests to others.
  • A person with approval authority, such as a homeowner or administrator, can accept or reject a callback.

In a word, the third generation solution launched by Rongyun — scenario-based SDK, the core idea is to liberate developers from tedious development, help them liberate productivity, invest more energy in product innovation, open up new battlefields, attract new customer groups, and harvest new growth.