Design practice of Rongyun IM on Electron platform

With its relatively lower R&D cost, strong cross-platform support, and a large audience of Javascript developers, Electron has emerged in the field of desktop application software development on the PC side.

This article aims to share the practical experience of Rongyun IM's desktop SDK product development on the Electron platform. Follow【 Global Internet Communication Cloud 】to learn more

Rongyun IM's Electron Desktop Solution Goals

1. Provide the ability to match with traditional desktop communication software Support

Compared with Web page applications with B/S architecture, Rongyun expects to provide developers with richer localization capabilities and a more efficient duplex communication channel than Websocket (or Comet) in the Electron environment.

With the help of these technical capabilities that are inconvenient to implement in the browser environment, we can improve the user experience of desktop products as a whole, and maximize the potential of Electron as a C/S architecture software running platform.

2. Browser is different from Electron and the runtime code is highly reused

Since Electron and standard web applications have almost the same technical ecology, most products require front-end code engineering to take into account both Browser and Electron. That is to say, a set of code should be packaged as a traditional desktop application and published to run in a browser. web application.

Based on this, Rongyun IM SDK, which is provided as a PaaS capability, needs to minimize differences under two different runtimes to avoid developers from writing redundant platform-compatible code.

3. It is convenient for developers to build multi-window and multi-process complex desktop applications

Electron provides a relatively complete cross-process communication solution for desktop application development by encapsulating IPC capabilities. With this capability, desktop applications built by developers are gradually becoming more complex.

Typical desktop communication products, usually use an independent window for basic IM chat services, and a window for historical chat record query services; when there is an audio and video conference business scenario, you need to open another window for conference services; even Some developers put forward the need to maintain an independent chat window with each chat object (product form such as QQ).

In this scenario, the maintenance of the long connection state and the synchronization of messages become extremely complicated. The reasons are as follows:

If each process window maintains an independent long-term connection, it is inevitable that the connection state of a process will be out of sync with the connection state of other processes; and developers need to maintain the connection state in each process at the same time, which is more complicated; at the same time, it will also cause service concurrency. Decrease in ability.

If there is only a single main window for connection maintenance, and other windows use the main window as a connection proxy through the IPC capability, it is necessary to maintain complex cross-process communication business codes in the main process and each rendering process, thereby increasing the overall complexity of the project.

The vast majority of current Electron developers are from Web developers. The existing programming thinking is built on the application model of single process and single thread in the browser page, and there is a lack of relevant product development for dealing with such a multi-process model. accumulated experience.

In order to reduce the complexity of business implementation in similar scenarios, Rongyun needs to solve the problems of multi-process connection sharing and multi-process message synchronization at the PaaS capability level, so that developers can realize each business more smoothly under the existing programming thinking mode.

4. Multiple versions of Rongyun IM SDK need to be synchronized

Rongyun's existing Web IM SDK has multiple versions, each version has a different number of customers, and the API interface design of each version is very different, and the cost of cross-version upgrade is high.

Considering the possibility of customers using different versions to migrate their business to Electron in the future, we expect to avoid excessive integration code modifications by existing customers through architectural design improvements, on the premise that existing customers will not be lost due to version upgrades It can reduce the maintenance cost of the multi-version SDK of the Web R&D team itself.

Goal landing promotion plan

1. Strip the common business and externally differentiated API definitions of each version

Each version of Rongyun's IM SDK is independently maintained in different code repositories and has nothing to do with each other, which leads to all functions (including the Electron desktop solution to be developed) may have to be implemented separately in each version repository, which not only costs high development , it will also lead to unguaranteed implementation quality, or inconsistent code implementation, and at the same time, it will also push up the cost of testing, online and other links in the follow-up process of production and research.

(different versions of IM SDK are maintained independently)

Based on the requirements of goal 4, continuing to develop under the existing status means that different implementations need to be made on the basis of the two versions, which neither conforms to the code aesthetics of programmers, but also affects the overall R&D efficiency of the team.

In order to better achieve Goal 4, the team decided to prioritize the existing business layering through refactoring. The business code required for each version is abstracted into the IM Engine package, and different APILayer is implemented for each version of the IM SDK to be compatible with the existing business code. The interface of the wired online version is aligned, which can not only reduce the R&D cost of the team, but also meet the subsequent upgrade needs of existing online customers.

(refactoring code, business layering)

After the layering is completed, other products that depend on the IM SDK, such as the RTC SDK, can also get rid of the dependence on the IM SDK interface and directly call the engine layer interface. When the business layer expands the RTC business, there is no need to consider the IM SDK. version problem.

(guaranteed scalability)

Another consideration for layering is to limit the interaction with the business layer to the API layer, and to deal with the code differences between Electron and Browser in the Engine, in order to achieve goal 2. The business layer only needs to care about the interface calls of the IM SDK. There is no need to care about the underlying differences, ensuring that the business layer needs to maintain little or no compatible code under the two runtimes, so that the business layer can focus more on business development.

2. Difference between Electron and IM SDK under Browser platform

After isolating the Engine from the business layer, it is necessary to consider the key capability differences of the Engine under different runtimes, and implement the underlying design of the Engine based on the capability differences.

Under the Browser and Electron platforms, the implementation methods from connection management to message sending and receiving are very different. The team needs to continue to layer the Engine package, define the capability interface of IM Engine through the AEngine abstract class, and abstract the APIContext class to manage the capabilities of AEngine transfer.

Considering the construction size of pure web applications, Electron's capability implementation code should not be packaged into standard web pages. Therefore, it is necessary to separate the implementation code under the Electron platform as an independent package (ElectronSolution) as an optional module. The developer chooses to install and use.

(Code extraction is an optional module)

As shown in the figure above, CppEngine is defined in the ElectronSolution package, which needs to be preloaded to the rendering process window by the developer through the webPreferences.preload configuration property when the Electron application creates a BrowserWindow instance.

When APIContext initializes an AEngine instance, it firstly checks whether CppEngine has been defined. When a CppEngine definition is found, CppEngine is initialized to provide richer localization capabilities, otherwise JSEngine is initialized.

const engine: AEngine = typeof CppEngine !== 'undefined'
  ? new CppEngine()
  : new JSEngine()

3. Solve the problem of multi-process message synchronization and multi-process connection sharing

In the current design of the ElectronSolution package, all code runs in the rendering process, which means that each process is independent of each other and maintains an independent process state, which cannot meet the needs of multi-process state synchronization and connection sharing in Objective 3.

In order to solve this problem, it is necessary to put the CppProto.node module in the main process, and realize the connection management, message sending and receiving capabilities in the main process, and multiple rendering processes share the main process state through IPC communication.

(Multiple rendering processes share the main process state through IPC communication)

In order to achieve the requirements of Objective 3, ElectronSolution needs to be split into two subpackages: Main and Renderer

The Main package runs in the main process and is responsible for maintaining the invocation of the CppProto.node module, implementing underlying connection management, message management and other functions, and maintaining communication with each rendering process through the ipcMain provided by Electron

The CppEngine class is defined in the Renderer package, which inherits from the AEngine abstract class in the Engine package. It is still used as a proxy for the main process through webPreferences.preload, and maintains communication with the main process through ipcRenderer.

(Main and Renderer subpackages)

After the modification is completed, the overall structure of the ElectronSolution package is basically determined. The key directory structure of the ElectronSolution package is listed below for reference.

node_modules/@rongcloud/electron-solution
├── index.js
├── main
│   ├── addon
│   │   ├── binding
│   │   │   └── electron-v{electron-version}-{platform}-{arch}.node
│   │   └── index.js
│   ├── dist
│   │   └── index.js
│   ├── index.js
│   └── package.json
└── renderer
│   ├── dist
│   │   └── index.js
│   ├── index.js
│   └── package.json
└── package.json

Based on the above architectural changes, when the business layer needs to implement IM capabilities in multiple rendering processes, it only needs to pay attention to the IM SDK interface calls in each process, and ElectronSolution handles the state synchronization between multiple processes.

When the developer expects to migrate from the existing web business to the Electron platform, the developer does not need to modify the existing web business code, but only needs to incrementally write the main process code to implement related functions, and install and integrate ElectronSolution into the Electron desktop application. That's it.

Overall structure display

Future Planning of Rongyun Electron Platform

As a safe and reliable global Internet communication cloud service provider, Rongyun will continue to develop RTC scenario capabilities under this platform in addition to its continuous in-depth cultivation of IM-related businesses.

At present, the WebRTC capabilities originally provided by Chromium under the Electron platform are relatively weak for the development of desktop-level audio and video application software. Rongyun will explore how to use the expansion capabilities of node.js to provide more underlying WebRTC capabilities such as sound effects, sound quality, Video effects, etc.

In addition to more in-depth capability expansion, Rongyun will also provide a comprehensive desktop-level application development framework to provide developers with more comprehensive Electron capability encapsulation, and standardize the code organization and script construction process of developers to facilitate developers in When dealing with complex and large desktop applications, focus more on the business itself.

At the same time, Rongyun has always insisted on continuous investment in technology, constantly consolidating the underlying technology, and strengthening the cornerstone power. Continue to explore front-end technologies other than Electron, and insist on self-iteration and technical excellence, in order to bring more practical and easy-to-use products to the majority of developers.