Frontend Development 12 min read

Frontend Architecture of 58 MicroChat: Multi‑Platform Design and Implementation

The article describes the layered front‑end architecture of 58 MicroChat, covering its network, SDK, UI, integration, storage, security, polyfill, and quality‑monitoring modules, as well as the message center design, cross‑platform compatibility strategies, and ongoing quality‑monitoring practices.

58 Tech
58 Tech
58 Tech
Frontend Architecture of 58 MicroChat: Multi‑Platform Design and Implementation

Introduction

Communication is the foundation of human existence. On 58.com, the largest classified‑information service platform in China, 58 MicroChat acts as the communication link.

58 MicroChat carries the mission of serving users, connecting teams, and supporting the future. It has been integrated into major business lines such as real‑estate, recruitment, used‑car, and yellow‑pages, subtly driving the growth of 58.com and aligning with the mission “making life simple and beautiful through the Internet”.

As an instant‑messaging tool, 58 MicroChat provides full‑stack support for Android, iOS, PC, Web, WAP, and mini‑programs. The following sections analyze its front‑end technical architecture.

Overall Architecture

The diagram above shows the overall front‑end system architecture, which is divided into four layers—Network, SDK, UI, and Integration—as well as auxiliary modules such as Storage, Security, Quality Monitoring, and Polyfill.

Functions of each layer and module:

Network Layer: Provides unified short‑connection and long‑connection interfaces.

SDK Layer: Offers unified business‑interface encapsulation and core business‑logic management.

UI Layer: Implements the most differentiated UI across platforms. The PC version must be IE8‑compatible and uses native module syntax; the mobile (M) version uses the Vue framework; the mini‑program version uses native mini‑program syntax due to framework limitations.

Integration Layer: Supports multiple independent business lines (58, Ganji, Anjuke, etc.) each with its own account system and product variants. A default UI is provided for customization, or businesses may integrate only the SDK and implement their own UI.

Storage Module: Abstracts platform‑specific local storage differences and offers a unified access API.

Security Module: Encrypts request data to prevent low‑cost interface simulation and filters rendered data to mitigate XSS attacks.

Polyfill Module: Manages a collection of polyfills for convenient, high‑performance APIs while ensuring cross‑platform compatibility.

Quality Monitoring Module: Reports key metrics from user scenarios, collecting issues not discoverable during development or testing to support data‑driven optimization.

Message Center

The Message Center is the core function of the SDK layer. It receives messages pushed from the server via WebSocket or HTTP long‑connection (referred to as “channels”). Both channel types consume significant resources on the server and client.

Opening multiple pages on PC would normally create multiple channels, leading to massive resource consumption, especially on the server side.

To address this, a multi‑page message synchronizer (Message Manager) was designed to ensure that only one channel exists per browser instance, with all messages routed through this single channel.

Two core problems were solved:

Problem 1: Ensuring a single channel. All pages share a heartbeat stored locally; the page that holds the channel updates the heartbeat every 3 seconds, while other pages check the heartbeat every 5 seconds. If the heartbeat is stale, a new channel is created.

Problem 2: Synchronizing messages across pages. Instead of each module polling local storage, a unified Message Manager provides a publish/subscribe interface. Modules subscribe to specific message types and receive updates automatically.

The Message Manager handles two main tasks: receiving channel messages and writing them to local storage, and periodically reading local storage to invoke callbacks for subscribed modules.

Message Center Flow:

Message Manager Class Diagram:

Cross‑Platform Compatibility

58 MicroChat’s front‑end project is widely used across the 58 Group.

Supported platforms include PC, mobile (M), and mini‑programs.

Business lines such as 58, Ganji, and Anjuke each have distinct account systems.

Browser compatibility requirements: PC must support IE8 and below; mobile must support IE9+; mini‑programs have minimal compatibility concerns.

Because of the high overlap in business logic across the three fronts, the SDK layer is unified and developed centrally to maximize code reuse and reduce maintenance cost, while the UI layer—being highly divergent—remains independently developed for each platform.

Although ES6 has been standardized for years, browsers older than IE9 do not even support ES5, preventing direct use of many modern syntactic sugars. However, polyfills for methods such as Function.prototype.bind and Function.prototype.filter are mature. The project adopts new syntax in business code but only includes the necessary polyfills in the Web SDK, ensuring modern syntax usage without inflating the bundle size for platforms that do not need them.

Quality Monitoring

Network conditions, devices, operating systems, and user environments vary dramatically, making it impossible for developers and testers to cover every scenario.

To gain insight into real‑world usage, a front‑end quality‑monitoring component was built to report key metrics from user scenarios, capturing issues that are invisible during development and testing.

Key metrics collected include:

Error Logs: Capture bugs before large‑scale user feedback, enabling faster resolution and reducing user impact.

Performance Indicators: Provide baselines for performance optimization and allow quick visualization of improvement trends.

Hijack Information: Monitor website security status, guiding future security strategies such as CSP and RSI.

Conclusion

As a core service across the 58 Group, the 58 MicroChat front‑end project connects various user groups and continuously evolves. After one to two years of feature iteration, the project grew complex, prompting ongoing refactoring to maintain a layered structure.

Technology evolves, and systems must keep pace. In the short term, we will leverage quality‑monitoring data to target code‑quality and performance improvements. In the medium to long term, we will explore and pilot emerging technologies such as PWA, CSP, and WebRTC for future integration.

frontendCross-PlatformarchitectureMessagingpolyfillquality monitoring
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.