How to Build Scalable Web Platforms with AOP‑Driven Adaptation

Scalability is a design metric for a software system's processing capacity; high scalability means elasticity, allowing the system to grow with minimal changes.

Considering scalability during design reduces future maintenance costs, improves ROI estimation, and enhances disaster recovery and user experience.

Scalability in Web Interactive Systems

It manifests in two dimensions:

Platform scalability – the ability to quickly support new platforms and gracefully retire obsolete ones.

Module scalability – maintaining clean, modular code as features evolve.

Typical applications include desktop/mobile websites, hybrid mobile apps, and desktop hybrid apps.

Platform Scalability

Key aspects are:

Expandability: rapid support for emerging platforms.

Reducibility: minimal changes to remove outdated platform code.

Platform Classification

Platforms are divided into browser platforms and hybrid‑app platforms.

Browser Platforms

Classified by rendering engine:

Hybrid‑App Platforms

Based on the host environment:

Android – uses WebKit.

iOS – uses WebKit.

Windows Phone – uses Trident.

PC – uses CEF with WebKit.

Platform Adaptation via AOP

Aspect‑Oriented Programming separates cross‑cutting concerns from core business logic, allowing platform‑specific adjustments to be encapsulated as aspects.

Standard business logic follows W3C/ES standards, while each platform adds pre‑ and post‑aspects that modify behavior before or after the core logic.

Code Comparison

Traditional approach mixes all platform checks inside the main function:

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 w3c implement */ }
}
// usage
doSomething(1,2,3);

Problems: tight coupling, need to modify core logic for each platform, and inability to exclude unnecessary platform code.

AOP‑based approach isolates the core function and applies platform aspects separately:

function doSomething(){ /* TODO w3c/es implement */ }
// usage
doSomething(1,2,3);

Platform‑specific files (e.g., trident.js) use _$aop to wrap the core function with before/after logic.

doSomething = doSomething._$aop(
    function(_event){ /* TODO trident before */ },
    function(_event){ /* TODO trident after */ }
);

This separation yields:

No coupling between core and platform code.

Adding a new platform only requires a new aspect.

Configuration can enable or disable platform support.

Implementation Example with NEJ Framework

NEJ provides a configuration‑based platform adaptation system.

Typical widget module:

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

The {platform}api.js file contains standard APIs, while {platform}api.patch.js defines platform‑specific patches using NEJ.patch:

NEJ.define(['./hack.js'], function(h){
    // Trident specific logic
    NEJ.patch('TR', function(){ /* TODO */ });
    // Gecko specific logic
    NEJ.patch('GR',[ './hack.firefox.js' ], function(){ /* TODO */ });
    // IE6 specific logic
    NEJ.patch('TR==2.0',[ './hack.ie6.js' ]);
    // IE7‑IE9 logic
    NEJ.patch('3.0<=TR<=5.0', function(){ /* TODO */ });
    return h;
});

By configuring the target platforms in the script URL, only the necessary patches are bundled, avoiding any impact on other platforms.

<script src="/path/to/nej/define.js?p=wkgktd"></script>
<script src="/path/to/nej/define.js?p=cef"></script>

Platform Changes: Extension and Reduction

When a new platform is added, define a new identifier, implement its patch, and include it in the configuration.

When a platform is retired, remove its identifier from the configuration, and the related code is excluded without touching core logic.

The next article will discuss module scalability.