The CloudBrowser Web Application
Framework
Brian McDaniel
5/2/12
Outline
Overview of Web Applications



AJAX Web Applications
Server-centric Web Applications
CloudBrowser Web Applications
Demo
Implementation
Evaluation
Related and Future Work
Conclusion






2
Software Trends
Applications moving from the desktop to the web.


Email (Gmail), Word Processing (Google Docs)
Users expect these applications to behave like desktop
applications.


3
Rich user interfaces; interactivity
Web Applications
The Web wasn’t designed for applications.


Originally for sharing static documents
JavaScript was added to allow some simple interactions
with web pages.
The basic building blocks are repurposed to create web
applications:




4
Document - > GUI
JavaScript -> Application Development Language
Web Application Styles
Multi-page Applications





5
Similar browsing to static documents.
HTML dynamically generated by server.
Each view has a unique URL.
Navigating between views causes a full refresh.
Single-page AJAX Applications
Single-page AJAX Applications



Initial page loaded, then AJAX requests to load additional data
and modify view.
Closer to desktop application experience.
Server Machine
www.gmail.com
AJAX Request
AJAX +
Response
HTML
JavaScript
AJAX
Request
Request
Application
HTTP
Response
Code
HTML
+
Server AJAX
JavaScript
6
Issues with AJAX Web Applications
Client-side state is transient.



Lost on page refresh and navigation.
Reconstructing client-side state is difficult.

No unique mapping of URLs to particular views.
Changing programs requires both client and server
programming.
Model-View-Controller pattern is distributed.



Distributed controller logic.
Network programming manually handled by developer.

7
Server-centric Web Applications
Client Browser
DOM
Events
Server Machine
www.app.com
HTML + JS
Changes
Modifications
Instantiates
JavaScript
Engine
Client
Engine
8
HTTP HTML Application
Server + JS
Code
Components
Update Instructions
Events
Events
Issues with Existing Server-centric
Frameworks
Client-side state is still transient.



Components instantiated on each request.
Client state must be manually reconstructed.
Difficult to debug due to component translation process.
Designers and developers must learn new markup and
programming languages.


9
CloudBrowser
Client Browser
DOM
Events
Server Machine
www.app.com
Client
Engine (JavaScript)
Changes
Construct
10
Application
Code
Modifications
Instantiates
JavaScript
Engine
Client
Engine
HTTP
Server
Loads
Events
Virtual Browser
Request
for DOM
Update
Instructions
Serialized
Events DOM
DOM
CloudBrowser

Virtual browser lifetime decoupled from client lifetime.



Server-centric application model for developers.


Client/server communication details hidden from developer.
Applications written in pure JavaScript, HTML, and CSS.



Clients can disconnect and reconnect – state is saved.
Provides natural co-browsing support.
No component translation process.
Allows use of existing client-side libraries.
No rendering/layout computation on the server.
11
Demo – Meeting Scheduler
14
Demo – Meeting Scheduler


66 lines of CoffeeScript, 108 lines of HTML
Leverages existing client-side libraries:





jQuery: DOM manipulation
Bootstrap CSS: styling
Knockout.js: data bindings and templating
Moment.js: time strings
Co-browsing based application.

15
Real-time collaboration for free.
Demo – Meeting Scheduler

Creating the “possible times” list:
model =
...
possibleTimes : ko.observableArray()
...
<div id='timeList' style='padding-top: 20px'>
<h4>Possible times:</h4>
<ul data-bind=“foreach: possibleTimes”>
<li data-bind="text: $data"></li>
</ul>
<button id='send-mail' class='btn btn-primary'
data-bind=‘visible: possibleTimes().length != 0’>
Send Reminder E-mail
</button>
</div>
16
Demo – Meeting Scheduler

E-mailing participants:
smtp = require('nodemailer')
smtp = nodemailer.createTransport 'SMTP',
service: 'Gmail'
auth:
user: 'cloudbrowserframework@gmail.com'
pass: 'topsecret'
$('#send-mail').click () ->
for p in model.participants()
addr = p.email()
continue if addr == 'none'
msg = "Hey #{p.name()}, here are the available times:\n"
msg += "\t#{time}\n" for time in model.possibleTimes()
mail =
from: "CloudBrowser <cloudbrowserframework@gmail.com>"
to: addr
subject: "Available Meeting Times"
text: msg
smtp.sendMail(mail)
17
Storing Model Data

3 ways:

All data in virtual browser.


Shared data as JavaScript objects, accessible from multiple
virtual browsers.


ex: chat room application
Traditional means, such as a database or file system.

18
ex: meeting scheduler
Useful when model storage needs to be scaled.
Implementation





Implementation Platform
Processing Client Events
Synchronization Protocol
Detecting Virtual Browser Changes
JavaScript Execution
19
Implementation Platform

Node.js





JSDOM


Built on Google ‘s V8 JavaScript Engine
One language client- and server-side
Automatic integration with virtual browser
Large library ecosystem
Node.js W3C DOM implementation
Socket.io

20
2-way socket connection between browser and server
Client-side Events
Client Browser
Server Machine
DOM
Events
HTTP
Server
Changes
Modifications
JavaScript
Engine
Client
Engine
21
Application
Code
Virtual Browser
Update Instructions
Events
DOM
Events
Processing Client Events

Block client-side event processing.

Register capturing event listeners on those events.


22
Call event.stopPropagation().
Call event.preventDefault().
Synchronization Protocol
Client Browser
Server Machine
DOM
Events
HTTP
Server
Changes
Modifications
JavaScript
Engine
Client
Engine
23
Application
Code
Virtual Browser
Update Instructions
Events
DOM
Events
Synchronization Protocol:
Communication

We establish RPC endpoints on the client and server.
Client Methods
PageLoaded(records)
DOMNodeInsertedIntoDocument(records)
DOMNodeRemovedFromDocument(records)
DOMAttrModified(target, name, value)
DOMPropertyModified(target, property, value)
DOMCharacterDataModified(target, value)
DOMStyleChanged(target, attribute, value)
AddEventListener(target, type)
PauseRendering()
ResumeRendering()
24
Server Methods
processEvent(event)
setAttribute(target, attribute,value)
Detecting Virtual Browser Changes
Client Browser
Server Machine
DOM
Events
HTTP
Server
Changes
Modifications
JavaScript
Engine
Client
Engine
25
Application
Code
Virtual Browser
Update Instructions
Events
DOM
Events
Detecting Virtual Browser Changes

Changes detected using aspect-oriented programming.


Add wrapper methods (advice) around DOM manipulation
methods.
Example:
var oldMethod = DOM.Node.appendChild;
DOM.Node.appendChild = function () {
var rv = oldMethod.apply(this, arguments);
browser.emit('DOMNodeInsertedIntoDocument', {
target: arguments[0],
parent: this
});
return rv;
};
26
JavaScript Execution

Each virtual browser needs a faithful JavaScript
environment.




Must match existing browser environments.
Required to run existing client-side libraries.
Node.js doesn’t expose an API to provide isolated
execution environments with the right semantics.
We wrote Contextify, a C++ addon for Node

27
Adopted upstream by JSDOM.
Evaluation Goals




What is the latency cost of processing events on the
server?
What’s the memory cost of instantiating virtual browsers
on the server?
What’s the memory cost of adding additional clients to a
virtual browser (co-browsing)?
How good is our DOM implementation?
28
Evaluation Setup

Hardware:




Server: 2- 2.5 GHz quad-core processors, 16 GB RAM
Client: 3.00 GHz quad-core processor, 8 GB RAM
Connected by gigabit LAN.
Can’t use traditional benchmarking means.


29
CloudBrowser isn’t stateless.
We want to simulate user interactions with a virtual browser.
Latency

Response times (Nielson, Usability Engineering)




< 100ms: feels instantaneous.
< 1 second: noticeable, but doesn’t interrupt workflow.
Keynote Internet Health report considers latency < 90ms
between backbones as “good”.
Ping from Blacksburg to Austin, TX (measured by me):

30
~60 ms
Latency

Experimental setup:

Scripted client:


Connect to a new virtual browser.
while !done




31
Start clock.
Send a precomputed event.
Wait for response.
Stop clock; compute latency; save in results array.
Latency
32
Latency
33
Virtual Browser Memory Usage


Question: what’s the memory cost of a virtual browser?
Experimental procedure:



34
Connect a client to a new virtual browser (cause allocation).
Force a garbage collection.
Collect V8 heap memory usage (Node.js API)
Virtual Browser Memory Usage
Application
Hello World
Chat Room
Meeting Scheduler

Effect of JavaScript:




jQuery: 1.05 MB
Knockout.js: 0.33 MB
Moment.js: 103 KB
Effect of CSS:

35
Bootstrap: 820 KB
Memory Usage
164 KB
2.58 MB
4.45 MB
Additional Client Memory Usage


Question: what’s the memory cost of adding clients to a
single virtual browser?
Experimental procedure:




Connect a scripted client to the virtual browser.
Force a garbage collection.
Collect memory usage.
Result: ~16 KB per connected client
36
DOM Conformance

jQuery Test Suite Results
Test Suite
Core
Callbacks
Deferred
Support
Data
Queue
Attributes
Events
Selector
Traversing
Manipulation
CSS
AJAX
Effects
Dimensions
Exports
Offset
Selector (jQuery)
37
Pass
1306
418
155
28
290
32
453
476
310
297
530
58
329
367
61
1
N/A
N/A
Total
1309
418
155
38
290
32
473
482
314
298
547
93
349
452
83
1
N/A
N/A
% Passed
99.77%
100.00%
100.00%
73.68%
100.00%
100.00%
95.77%
98.76%
98.73%
99.66%
96.89%
62.37%
94.27%
81.19%
73.49%
100.00%
Limitations with CloudBrowser Approach

No access to computed layout

Can’t support libraries that rely on client-side layout
information.



element.offsetWidth, element.offsetTop, etc.
CSS3 can eliminate this need for many use cases.
Latency-sensitive applications (e.g. games)

38
Not every application should be a CloudBrowser application.
Limitations with CloudBrowser
Implementation

DOM conformance



Lacking support for browsing pages in the wild.
As JSDOM implementation improves, so does CloudBrowser.
Multi-core scaling



39
Node.js is single threaded.
Need to distribute framework to multiple procceses.
Initial implementation done, but requires improvement.
Related Work

ZK



Server-centric, Java-based framework.
Uses components; instantiated on each request.
ItsNat



40
Server-centric, Java-based framework.
Uses a DOM on server.
Applications written in HTML, CSS, and Java.
Future Work




Multi-process scaling improvements.
Improved CloudBrowser API.
Improved DOM conformance.
Virtual browser management:


41
Persistence
Garbage collection
Conclusion




CloudBrowser is a server centric web application
framework where applications run in virtual browsers on
the server.
User interface state is automatically preserved across
navigation, refresh, and disconnection.
CloudBrowser introduces acceptable latency and
memory overhead for many use cases.
The distributed nature of web applications is hidden from
developers.
42
Questions?
43
Scaling to Multiple Processes
pipe
Virtual
Browser
pipe
Virtual
Browser
pipe
Virtual
Browser
Client
Browser
Front-end Server
app1
Server
(multiprocess)
app2 Server
(single-process)
Virtual
Browser
44
Virtual
Browser