Look at the evolution of PaaS services from the birth of Yuchaofang SDK

[Follow Global Internet Communication Cloud ] discussing 16177a070a630e, let’s look at a piece of Javascript pseudo-code.

// 加⼊聊天室，获取收发消息和信令能⼒
IMClient.shared.join(roomId, (isSuccess, error) => {
if(isSuccess) {
// 加⼊RTC Room 获取⾳频流和发布⾳频流能⼒
RTCClient.shared.join(roomId, role, (isSuccess, error) = > {
// 根据⾓⾊确定⽤户⾏为，是订阅⾳频流还是发布⾳频流
if(role == Audience) {
RTCClient.subscribeStreams(streams, (error) => {
})
} else {
RTCClient.publishStreams(streams, (error) => {
})
}
})
} else {
console.log(error)
}
})

Conventional language chat room solution

The above code shows the common language chat room solution in the industry, that is, the process of using IM and RTC capabilities to create a language chat room.

Based on this solution, developers need to deal with the following issues:

Maintain IM Room and RTC Room at the same time

Need to judge the subscription and release of the stream according to the role

Need to deal with different error messages

Next, let's take a look at the basic process of using the conventional program to deal with the common operations of the language chat room.

(Basic process of maiming)

The logic that developers need to deal with is as follows:

Store wheat position information

After updating the wheat position information, synchronize the wheat position information of all users in the room

The audio stream is released when the microphone is on, and the audio stream is unpublished when the microphone is off

The logic of switching the subscription stream between up and down microphones (if the role of the host needs to subscribe to other anchors, if the role is the audience, it needs to subscribe to the host combined stream)

The conclusion is that if the developer develops the language chat room based on the underlying SDK of the PaaS service, it is time-consuming and labor-intensive, and needs to deal with a lot of business logic.

The evolution of language chat room solutions

In fact, the above solution is already the second-generation language chat room solution, and it is also the mainstream solution provided by various PaaS service vendors.

Let's briefly introduce the evolution process of the language chat room solution.

The first thing that needs to be clear is that the core of the language chat room is how to better manage the wheat position.

The language chat room solution has gone through 3 stages.

The first generation is based on business server management: PaaS service providers provide back-end and front-end open source codes, and developers carry out secondary development based on this. That is, the front-end calls the back-end interface through the Restful interface, and the business server maintains the synchronization and update of the wheat position information.

The second generation is based on the front-end + sample project two-open method: that is, manage the microphone and directly modify the chat room properties through the front-end IM SDK to maintain and modify the microphone information, without the participation of the business server, and can be combined with the RTC SDK to achieve audio stream changes and changes. subscription. In addition, the manufacturer provides the corresponding open source code, and the developer can open it according to the open source code.

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

We compare the pros and cons of each program from the three dimensions of learning difficulty, development difficulty, and scalability.

Learning difficulty

The first-generation solution is based on the business server to maintain and manage the wheat position information. Developers need to handle the complex logic of multi-user wheat position synchronization and stream management. Moreover, if you want to implement a complete language chat room project from 0 to 1, you need to access and learn the open source code of the front and back ends at the same time, which is very difficult.

The second-generation solution is based on the front-end directly calling the storage capacity management of the IM SDK, eliminating the need for the business server to manage the microphone, which is relatively simplified, but developers still need to learn the various capabilities of the underlying SDK.

The third-generation solution, on the basis of the second-generation solution, encapsulates the basic capabilities into an API close to the business scenario, so that developers do not need to understand the underlying implementation, only need to understand the product concept to quickly get out of life, from 0 to 1 development complete Language chat room project.

Development difficulty

The first-generation solution requires simultaneous access to two sets of codes at the front and back ends, which is extremely difficult to change.

The second-generation solution needs to be changed on the basis of understanding the use of the underlying SDK. It is difficult to carry out secondary development without a thorough understanding.

The third-generation solution only needs to understand the product concept, whether it is based on SDK development or sample development, it can be easily mastered.

Due to the high learning cost and development difficulty of the first-generation solution, it is difficult to expand new gameplay and modes when developing.

The second-generation program development difficulty and learning cost have been reduced to a certain degree, and the scalability is limited to the understanding of open source code.

The scalability of the third-generation solution is based on whether the extended attributes provided by the SDK are rich, and it depends on the degree of encapsulation.

(Comparison of three-generation solutions)

Sample display of the third-generation solution

As the saying goes: Talk is cheap. Show me the code. We use some examples to show why the scene-based SDK is a better solution, which directly pushes the industry into a new stage of development.

First of all, users get access to the microphone.

/// ⽤户主动上⻨
/// @param seatIndex ⻨位序号
/// @param successBlock 上⻨成功
/// @param errorBlock 上⻨失败
- (void)enterSeat:(NSUInteger)seatIndex
success:(RCVoiceRoomSuccessBlock)successBlock
error:(RCVoiceRoomErrorBlock)errorBlock;

This is the microphone loading operation encapsulated in Rongyunyuchaofang SDK. Developers don't need to pay attention to the information update and synchronization of the microphone, and do not need to care about the subscription and release of the stream. As long as the serial number of the microphone is entered, all the details have been implemented in the SDK.

Let's take a look again, the common application in the language chat room scene, the general process is as follows:

(Applying process)

The cumbersome mechanism of applying for the microphone and agreeing to the microphone has been simplified into two APIs and a callback, which concisely and efficiently implement the complex microphone mechanism.

The user who wants to access the microphone calls requestSeat to send the microphone request to others;

People with review rights, for example, after the homeowner or administrator triggers a callback, they can agree or reject the other party's access to the microphone through accept or reject.

All in all, the third-generation solution launched by Rongyun—Scenario 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, and attract New customer base and new growth.