Building a Fast, Updatable PC Client with Electron for Classroom Interaction

Technology Stack Choice

Because the team consisted of web developers (frontend + backend), using WPF would require learning a new framework, resulting in low efficiency. The goal was to quickly iterate a PC client by reusing existing web resources.

At that time Electron had just released version 1.0, offering cross‑platform development, JavaScript‑based coding, and a rendering process that is essentially a browser, allowing reuse of web components.

Cross‑platform development

Direct JavaScript development

Rendering process is a browser, enabling reuse of web UI

Electron therefore helped frontend developers rapidly build the PC client.

Drawbacks of Electron include lack of Windows XP support, relatively large installation packages (starting at ~50 MB), and the need for Aero effects on Windows 7 when displaying irregular windows.

After discussion with the product team, the drawbacks were deemed acceptable for the target users, while the high development efficiency promised significant benefits, leading to the decision to adopt Electron.

Initial Architecture (Black Iron Era)

To quickly capture market share and enable hot updates, the design assigned the main process and window management to Electron, while window content was uniformly provided by the web side.

Architecture diagram:

Description

The Electron main process manages windows; communication between windows occurs via IPC with the main process, which forwards messages to the appropriate renderer process.

Business logic in the renderer process is fetched from the web service, essentially loading remote pages in a local browser.

When functionality or content needs updating, only the web service must be updated.

Summary

The main advantage of this architecture is the reuse of the web side, allowing rapid market entry and fast content iteration similar to web pages.

The downside is that the application depends on the web service; slow network leads to slower startup, and major version upgrades require updating both the installation package and the web service.

Architecture Improvement (Bronze Era)

To achieve faster startup and timely content updates, the following adjustments were made.

Main Architecture

Window Manager Relationship

Description

As window functionality grew, a dedicated Window Management Center was extracted; the BaseWindow class encapsulates window operations and automatic error handling.

The renderer process always obtains critical static resources via a Service Worker, dramatically accelerating startup. The Service Worker caches resources on first load, then checks for updates and persists them for subsequent launches.

Because communication mainly uses IPC, a MessageCenter class was introduced to manage all application messages and overall state.

Summary

The revised architecture speeds up application launch, retains hot‑update capabilities, and enables rapid feature iteration.

The drawback remains: major version upgrades still require simultaneous updates of the web service and the installation package.

Architecture Further Improvement (Silver Era)

Major version upgrades introduced many native‑related features:

USB‑key login monitoring the computer’s USB port; inserting a specially crafted key logs the user in automatically.

Cross‑login with other Xiwo applications, enabling single sign‑on.

Interaction with other Xiwo apps for seamless functionality.

Offline mode that continues operation during network disruptions and syncs data once connectivity returns.

…and more.

To meet these requirements, the architecture was further refined.

Description

Window content moved from the web service to the local installation package, eliminating dependence on remote resources.

Upgrade functionality now uses Xiwo’s silent‑upgrade service for differential local updates, freeing the Service Worker from handling window content updates.

USB‑key login and silent‑upgrade services require native DLL interaction; the ffi module was introduced, encapsulated into sub‑modules that run in child processes to avoid blocking the Electron main process.

Both the renderer process and Service Worker still interact with the web service, but only for data APIs. The Service Worker caches data and synchronizes it when the network recovers, making the renderer unaware of connectivity changes.

Summary

Application functionality and content no longer depend on the web.

Hot updates are replaced by a silent‑upgrade service.

Service Worker ensures usability during network fluctuations.

Stronger integration with native interfaces and services.

Future updates will no longer need to update both the web service and the installation package simultaneously.

Outlook

Next improvement goals are clear:

Further encapsulate main‑process functionality to achieve high cohesion and low coupling.

Enhance monitoring, logging, and business‑data tracking, and continue to standardize and encapsulate these features.

Architecture Third Improvement (Gold Era)

This iteration focuses on redesigning and improving the main‑process modules.

Architecture diagram:

WinsMgr: Window manager responsible for creating and retrieving all windows; created windows register automatically, and are deregistered upon destruction.

Win: Business window class extending BaseWin.

BaseWin: Base window class encapsulating related methods.

BaseMsgMgr: Core module combining events and IPC, handling event listening and response for its class objects.

MsgCenter: Registers and manages BaseMsgMgr, facilitating message forwarding.

Plugin: Inherits from MsgCenter, encapsulating related event functionality.

Description

The core ideas are:

All events are uniformly packaged and dispatched through a low‑level message queue.

Whether the object is a main‑process instance, a window, or a plugin (ffi module), it inherits from the messaging module, allowing direct communication with any target object.

Explicit IPC usage is hidden; developers no longer need to call IPC directly, reducing communication chaos as the business expands.

Result

Even without registering IPC events in the main process, communication between renderer processes is possible, as shown in the diagram below.

Renderer process code example:

currentWin.on('move', () => {
    console.log('I am moving~');
});

const win2 = WinsMgr.findWinByName('win2');
currentWin.on(win2, 'move', () => {
    console.log('win2 is moving');
});

Conclusion

There is never a perfect architecture, only the most suitable one.

As business requirements evolve, we will continue to refine the architecture and code to improve robustness, scalability, functionality, and developer experience.