Dept of CS Colloquium 1

Building Web Applications For The Cloud

Godmar Back

9/14/2012

Dept of CS Colloquium 2

Do You Doodle?

9/14/2012

Dept of CS Colloquium 3

Today’s Web Technology Landscape

9/14/2012

Dept of CS Colloquium 4

Ok, Let’s Build That

• Model View Controller - MVC• Mock up a View (in Jade) and test it.• Write your Model (in CoffeeScript)• Two supporting classes • A model singleton.• and unit test it. – Yes, professional developers do that.

• Use AngularJS to create a descriptive Controller and wire the model to the view.

9/14/2012

Trygve M. H. Reenskaug(in 1979)

5

Presenting: The Meeting Scheduler

• The brand-new Meeting Scheduler Application

9/14/2012 Dept of CS Colloquium

Dept of CS Colloquium 6

Are We Done Yet?

• Wait…• Are we really running in the cloud?• No!• We’re running downloaded code in a

JavaScript sandbox on the machine in front of us.

9/14/2012

Dept of CS Colloquium 7

Reality Sets In

Client Server

9/14/2012

Dept of CS Colloquium 8

The Web Is A Distributed System

• Ok. Rethink.• Data must be kept on the server. Somehow.• Another technology pile:

– AJAX, CometD, JSON-P, REST, RPC• Model

– Another model? Model View View-Model?– Which parts should be kept on client? All? Some?– When to synchronize the client and server models?– Do I need a submit button?– What if the user refreshes or revisits the page?

• Looking for inspiration… 9/14/2012

Dept of CS Colloquium 9

Introducing CloudBrowser

Client Server

9/14/2012

cloudbrowser.cs.vt.edu

Dept of CS Colloquium 10

CloudBrowser Architecture

9/14/2012

Web Browser Server-side JS Environment (node.js)

JSDOM, Contextify

Virtual Browser

AppliesUpdates

Listens for Events

Forwards Events

Sends Updates

DOM

Web SocketConnection

Server Engine

JS Web Application

HTMLCSS, Images

JavaScriptApp-

lication Code

JSLibraries (jQuery,

AngularJS)

node.jsLibraries

Data Bindings

Other Tiers

Parses

DOM

Client Engine

DispatchesEvents

DeliversEvents

Modifies DOM

ObservesChanges

11

Implementation

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

12

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, e.g. email Controller

• JSDOM– Node.js W3C DOM implementation

• Socket.io– 2-way socket connection between browser and server

13

Processing Client Events

• Block normal client-side event processing– Register capturing event listeners on those events• Call event.stopPropagation()• Call event.preventDefault()

14

Synchronization Protocol

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

15

Detecting Server-side DOM Updates

• Changes detected using aspect-oriented method– 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;};

16

JavaScript Execution

• Each virtual browser needs a faithful JavaScript environment– Must match existing browser environments– Required to run existing client-side libraries

• Node.js didn’t expose an API to provide isolated execution environments with the right semantics– window === this?

• We wrote Contextify, a C++ addon for Node– Adopted upstream by JSDOM

17

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?

18

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

19

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

20

Latency

21

Latency (Human User)

22

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)

23

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

24

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

25

DOM Conformance

• jQuery TestSuiteResults

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

26

Limitations (1)

• 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– Can encapsulate client-side components

• Highly latency-sensitive applications (e.g. games)– Not every application should be a CloudBrowser

application.

27

Limitations (2)

• DOM conformance– Lacking support for browsing pages in the wild

(though remarkably good…)– As JSDOM implementation improves, so does

CloudBrowser• Multi-core scaling– Node.js is event-based & single-threaded– Need to distribute framework to multiple processes– Initial implementation done, but requires

improvement

28

Scaling to Multiple Processes

app2 Server(single-process)

ClientBrowser

Fron

t-end

Ser

ver

app1 Server

(multi-process)

Virtual Browser

Virtual Browser

Virtual Browser

pipe

Virtual Browser

Virtual Browserpipe

pipe

29

Related Work:Contemporary AJAX Web Applications

• E.g., insert (client-library) + (server-framework) here• Changing programs requires both client and server

programming.• Model-View-Controller pattern is distributed.

– Distributed controller logic.• 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

• Network programming manually handled by developer.

30

Related Work:Existing Server-centric Frameworks

• ZK, ItsNat, Echo2, Vadiin, IceFaces• 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

31

Future Work

• CloudBrowser as a PaaS offering• Multi-process scaling improvements• Improved CloudBrowser API• Improved DOM conformance• Virtual browser management:– Persistence– Garbage collection

32

Conclusion

• CloudBrowser is a server centric web application framework where applications run in virtual browsers on the server– Actual rendering takes place on the client

• User interface state is automatically preserved across navigation, refresh, and disconnect

• CloudBrowser introduces acceptable latency and memory overhead for many use cases

• The distributed nature of web applications is hidden from developers

Dept of CS Colloquium 33

Acknowledgements

• Brian McDaniel, Virginia Tech, MS 2012– Main implementer of CloudBrowser

• Open GRA Position Now• Supported by CAREER: CCF-SHF Advanced Execution

Environments for Next-generation Cloud Applications • Brian McDaniel & Godmar Back, The CloudBrowser

Web Application Framework, to appear at Systems, Programming, Languages and Applications: Software for Humanity (SPLASH’12) Wavefront, Oct 2012, Tucson AZ

9/14/2012