The CloudBrowser Web Application Framework

Brian McDaniel5/2/12

2

Outline Overview of Web Applications

AJAX Web Applications Server-centric Web Applications

CloudBrowser Web Applications Demo Implementation Evaluation Related and Future Work Conclusion

3

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. Rich user interfaces; interactivity

4

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: Document - > GUI JavaScript -> Application Development Language

5

Web Application Styles Multi-page Applications

Similar browsing to static documents. HTML dynamically generated by server. Each view has a unique URL. Navigating between views causes a full refresh.

6

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

Application Code

www.gmail.com HTTP Serve

r HTML + JavaScript

HTML + JavaScript

AJAX RequestAJAX Response

AJAX Response

AJAX RequestRequest

7

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.

8

Server-centric Web Applications

Client Browser

DOM

JavaScript Engine

Server MachineHTTP Serve

rApplicatio

n Code

Components

www.app.com

Instantiates

HTML+ JS

HTML + JS

Client Engine

Events

Events

EventsModifications

Update Instructions

Changes

9

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.

10

CloudBrowser

10

Client Browser

DOM

JavaScript Engine

Server MachineHTTP Serve

rApplicatio

n Codewww.app.com

Instantiates

Client Engine (JavaScript)

Client Engine

Events

Events

EventsModifications

Update Instructions

Changes

Virtual BrowserDOM

Loads

Request for DOMSerialized DOM

Construct

11

CloudBrowser Virtual browser lifetime decoupled from client

lifetime. Clients can disconnect and reconnect – state is

saved. Provides natural co-browsing support.

Server-centric application model for developers. Client/server communication details hidden from

developer. Applications written in pure JavaScript, HTML,

and CSS. No component translation process. Allows use of existing client-side libraries.

No rendering/layout computation on the server.

14

Demo – Meeting Scheduler

15

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. Real-time collaboration for free.

16

Demo – Meeting Scheduler Creating the “possible times” list:

<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>

model = ... possibleTimes : ko.observableArray() ...

17

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)

18

Storing Model Data 3 ways:

All data in virtual browser. ex: meeting scheduler

Shared data as JavaScript objects, accessible from multiple virtual browsers. ex: chat room application

Traditional means, such as a database or file system. Useful when model storage needs to be scaled.

19

Implementation Implementation Platform Processing Client Events Synchronization Protocol Detecting Virtual Browser Changes JavaScript Execution

20

Implementation Platform Node.js

Built on Google ‘s V8 JavaScript Engine One language client- and server-side Automatic integration with virtual browser Large library ecosystem

JSDOM Node.js W3C DOM implementation

Socket.io 2-way socket connection between browser and

server

21

Client-side Events

Client Browser

DOM

JavaScript Engine

Server MachineHTTP Serve

rApplicatio

n Code

Client Engine

Events

Events

EventsModifications

Update Instructions

Changes

Virtual BrowserDOM

22

Processing Client Events Block client-side event processing.

Register capturing event listeners on those events. Call event.stopPropagation(). Call event.preventDefault().

23

Synchronization Protocol

23

Client Browser

DOM

JavaScript Engine

Server MachineHTTP Serve

rApplicatio

n Code

Client Engine

Events

Events

EventsModifications

Update Instructions

Changes

Virtual BrowserDOM

24

Synchronization Protocol:Communication We establish RPC endpoints on the client and

server.Client MethodsPageLoaded(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()

Server MethodsprocessEvent(event)setAttribute(target, attribute,value)

25

Detecting Virtual Browser Changes

2525

Client Browser

DOM

JavaScript Engine

Server MachineHTTP Serve

rApplicatio

n Code

Client Engine

Events

Events

EventsModifications

Update Instructions

Changes

Virtual BrowserDOM

26

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;};

27

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 Adopted upstream by JSDOM.

28

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?

29

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. CloudBrowser isn’t stateless. We want to simulate user interactions with a

virtual browser.

30

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): ~60 ms

31

Latency Experimental setup:

Scripted client: Connect to a new virtual browser. while !done

Start clock. Send a precomputed event. Wait for response. Stop clock; compute latency; save in results array.

32

Latency

33

Latency

34

Virtual Browser Memory Usage Question: what’s the memory cost of a virtual

browser? Experimental procedure:

Connect a client to a new virtual browser (cause allocation).

Force a garbage collection. Collect V8 heap memory usage (Node.js API)

35

Virtual Browser Memory Usage

Effect of JavaScript: jQuery: 1.05 MB Knockout.js: 0.33 MB Moment.js: 103 KB

Effect of CSS: Bootstrap: 820 KB

Application Memory UsageHello World 164 KBChat Room 2.58 MBMeeting Scheduler 4.45 MB

36

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

37

DOM Conformance jQuery Test Suite Results

Test Suite Pass Total % PassedCore 1306 1309 99.77%

Callbacks 418 418 100.00%Deferred 155 155 100.00%Support 28 38 73.68%

Data 290 290 100.00%Queue 32 32 100.00%

Attributes 453 473 95.77%Events 476 482 98.76%

Selector 310 314 98.73%Traversing 297 298 99.66%

Manipulation 530 547 96.89%CSS 58 93 62.37%AJAX 329 349 94.27%

Effects 367 452 81.19%Dimensions 61 83 73.49%

Exports 1 1 100.00%Offset N/A N/A

Selector (jQuery) N/A N/A

38

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)

Not every application should be a CloudBrowser application.

39

Limitations with CloudBrowser Implementation DOM conformance

Lacking support for browsing pages in the wild. As JSDOM implementation improves, so does

CloudBrowser. Multi-core scaling

Node.js is single threaded. Need to distribute framework to multiple

procceses. Initial implementation done, but requires

improvement.

40

Related Work ZK

Server-centric, Java-based framework. Uses components; instantiated on each request.

ItsNat Server-centric, Java-based framework. Uses a DOM on server. Applications written in HTML, CSS, and Java.

41

Future Work Multi-process scaling improvements. Improved CloudBrowser API. Improved DOM conformance. Virtual browser management:

Persistence Garbage collection

42

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.

43

Questions?

44

Scaling to Multiple Processes

app2 Server(single-process)

ClientBrowser

Fron

t-end

Ser

ver

app1 Server

(multi-proces

s)

Virtual Browser

Virtual Browser

Virtual Browser

pipe

Virtual Browser

Virtual Browserpipe

pipe