"Forwarding" builds a highly scalable web-interactive system (top)

Translated from: http://kb.cnblogs.com/page/503460/

Scalability is a software system processing capability of the design indicators, high scalability represents a kind of elasticity, in the system expansion process, can guarantee exuberant vitality, through the few changes, can achieve the overall system processing capacity growth.

In the system design, fully consider the scalability of the system, on the one hand can greatly reduce the future maintenance costs, and help decision-makers on the return of investment can be more accurate estimates, on the other hand, highly scalable systems tend to have better disaster resilience, thereby providing a better user experience.

The scalability of Web Interactive system is mainly embodied in two aspects:

• Platform scalability: With the development of web technology, more and more platforms are starting to use web technology to build systems, on the one hand different platforms provide environmental support there are various differences, on the other hand with the development of the platform, there will be some old platform to exit the historical stage, the new platform to become the mainstream platform , so the web system needs to be able to respond to such changes quickly and it needs to have good platform scalability.
• The scalability of the module: as the system functions constantly adding and removing update requirements change, the system may become more complex, redundant information may be more and more, the impact of the changes may be more and more large, so good module scalability to ensure that the system has good maintainability, so that the system is always in the best state

The main applications of Web interactive systems include:

• Desktop/Mobile Website class system (such as NetEase cloud classroom, Easy letter Webim, Lofter Mobile Web Edition, etc.)
• Mobile hybrid applications (such as NetEase Cloud album ipad, Lofter, etc.)
• Desktop hybrid applications (such as NetEase Cloud Music pc version, NetEase email assistant, etc.)

This series of articles is divided into two main parts of the scalability of the elaboration, respectively, the scalability of the platform and the scalability of the module. This article is the first article in a series to discuss the scalability of the platform.

　　Scalability of the platform

The scalability of the Web interactive system to the platform mainly shows as follows:

• Scalability: Fast support for emerging platforms
• Scalability: For outdated platform redundancy information can be removed with minimal modification

Let's first introduce the target platform of the Web Interactive system.

　　Platform classification

According to the difference of the container, we divide the platform into two categories: browser platform and hybrid application platform. Detailed descriptions of the classifications are described below.

　　Browser platform

　　Divided by engine

Browser platform, according to the main engine can be divided into the following categories:

　　Hybrid Application Platform

Depending on the hosting platform of the hybrid application, we divide the target platform of the hybrid application into the following categories:

Host	Description
Android	Hybrid applications for Android, the browser engine is automatically adapted to WebKit
Ios	Hybrid applications for iOS systems, the browser engine is automatically adapted to WebKit
Winphone	Hybrid applications for Windows phone systems, the browser engine is automatically adapted to Trident
Pc	Desktop applications, using CEF as a container, the browser engine is automatically adapted to WebKit

　　Platform adaptation

AOP (aspect-oriented programming): A tangent-oriented programming paradigm, whose core idea is to separate crosscutting concerns from the main focus, so that problem codes in specific areas can be separated from standard business logic, There is no coupling between the primary business logic and the domain business logic.

Here we can learn from the AOP idea to implement the platform adaptation strategy, combined with different platform implementation of logic, we can think of the use of norms, standards to implement business logic of the part of our main focus, and different platforms can be used as a number of facets of the focus of attention to encapsulation, Each platform only needs to pay attention to the standard correction logic under its own platform, so the adaptation of different platforms can be realized by adding and removing platform-corrected plane logic.

When implemented we first extract the standard business logic, and then each platform according to the actual situation to achieve the modification of the business logic:

• Standard business logic: main focus, here is the use of business logic based on the user's and ES standards
• Pre-platform Remediation logic: domain-specific concerns, mainly based on platform characteristics of the standard under the platform, the correction logic will precede the standard logic execution
• Post-platform remediation logic: The previous platform remediation logic is also a domain-specific concern, and the remediation logic executes after the standard logic executes.

Based on this idea, we compare the following two sections of code:

Code one: The current common platform adaptation method

function dosomething () {    if (istrident) {        //TODO Trident implement    }else if (iswebkit) {        //TODO WebKit Implement    }else if (Isgecko) {        //TODO Gecko implement    }else if (ispresto) {        //todo presto implement    }else{        //TODO implement    }}//Upper application using dosomething (All-in-A-Class);

This approach is implemented in the main logic for all platform remediation logic and has the following drawbacks:

• The platform-specific modification logic coupling in the main logic, the platform-specific update will inevitably cause the main logic to update
• Support for new or removed platforms must be modified to the primary business logic
• Unable to isolate unnecessary platform corrections, such as WebKit engine-based mobile platform applications that do not require remediation logic for other platforms

Code two: A platform adaptation approach using the AOP idea

function dosomething () {    //TODO w3c/es implement}//Upper application using dosomething (All-in-A-Class);

The logic for Trident platform adaptation, such as the Trident.js

Trident implementdosomething = DOSOMETHING._$AOP (    function (_event) {        //TODO Trident implement    },    function (_event) {        //TODO Trident implement    });

Compared with the code one, we can find that the interface adaptation of the AOP idea separates the standard business logic and the platform-specific business logic, whether to increase the platform-specific business logic does not affect the execution of the main business logic, but for the platform correction logic can be directly through the configuration of the way to add and delete, So we can get the following benefits from this:

• The main logic and platform-specific logic is not coupled, can be separated and integrated freely
• Add platform-specific logic for new platform adaptation without impacting the primary business logic
• Selectable export platform-specific business logic through configuration control-supported target platforms

　　Implementation examples

The Nej framework provides a configuration-based platform adaptation system for reference to the AOP idea, and for more information on this section, refer to Nej's dependency management system and platform adaptation system for more detailed information, with an example of how to use the adaptation in Nej.

A typical adaptation control structure is as follows:

The widget.js here is the control business logic implementation file, which relies on the API with platform differences in the implementation of this control, and its dependency code is as follows

Nej.define ([    ' util/event ',    ' {platform}api.js '],function (t,h,p) {    //TODO});

Here's how {Platform}api.js is handled as shown here./Relative to the current code file, which is the directory where the Widget.js file resides

The Api.js file here is a standard implementation logic that requires leveling the API, while the Api.patch.js file uses the Nej.patch interface to make on-demand adaptation logic for each platform, while packaging also provides on-demand output based on the condition recognition of the platform in the Nej.patch interface, as the Api.patch.js file eventually Is output on demand, it is not allowed to include other business logic in this file, in addition to using Nej.patch as a platform adaptation logic.

This file can only be defined nej.patch non-executable other business logic//packaged output only according to the platform configuration output required processing logic//real-time requirements, you can separate the platform-related part logic into a separate module nej.define ([    './hack.js '], Function (h) {    //processing logic for Trident platform    Nej.patch (' TR ', function () {        //TODO    });    Processing logic for the Gecko platform    nej.patch (' GR ', [        './hack.firefox.js '    ],function (FH) {        //TODO    });    Processing logic for the IE6 platform    nej.patch (' tr==2.0 ', ['./hack.ie6.js ']);    Processing logic for IE7-IE9    nej.patch (' 3.0<=tr<=5.0 ', function () {        //TODO    });    This must match the return value of the Hack.js file to    return h;});

Finally, we only need to configure the target platform of the product to output the corresponding adaptation of the platform, without the additional impact of other platforms:

<script src= "/path/to/nej/define.js?p=wkgktd" ></script><script src= "/PATH/TO/NEJ/DEFINE.JS?P=CEF" ></script>

　　Platform changes

By implementing the above example we can see that when the platform changes we can quickly expand or reduce

　　Platform Extensions

When a new platform is needed as a system target platform, we only need to do the following:

• Add platform configuration identifiers, such as Nxw
• Identify differences between the platform and standards, and increase the platform-specific business logic to patch

• The system adds a new identifier to the platform configuration section, such as

  Original platform adaptation: <script src= "/PATH/TO/NEJ/DEFINE.JS?P=WKGKTD" ></script>

  New platform adaptation: <script src= "/path/to/nej/define.js?p=wkgktdnxw" ></script>

Can complete the expansion of the platform without affecting the original business logic.

　　Platform reduction

When the system is adapted to the target platform for some reason to exit the historical stage, the system also needs to remove the platform's redundant code from the system, we only need to do the following work:

• The system will remove the platform identity from the Platform configuration section, such as:

  Original platform adaptation: <script src= "/PATH/TO/NEJ/DEFINE.JS?P=WKGKTD" ></script>

  Reduced platform adaptation: <script src= "/path/to/nej/define.js?p=wk" ></script>

The platform can be scaled down without having to modify any business logic.

The above is an introduction to platform extensibility. The next article will explain the scalability of the module, please look forward to!

This work is licensed using the Creative Commons Attribution 4.0 International license.

"Forwarding" builds a highly scalable web-interactive system (top)