340 likes | 463 Views
Building Web Applications For The Cloud. Godmar Back. Do You Doodle?. Today’s Web Technology Landscape. 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 .
E N D
Building Web Applications For The Cloud Godmar Back Dept of CS Colloquium
Do You Doodle? Dept of CS Colloquium
Today’s Web Technology Landscape Dept of CS Colloquium
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. Trygve M. H. Reenskaug(in 1979) Dept of CS Colloquium
Presenting: The Meeting Scheduler • The brand-new Meeting Scheduler Application Dept of CS Colloquium
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. Dept of CS Colloquium
Reality Sets In Client Server Dept of CS Colloquium
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… Dept of CS Colloquium
Introducing CloudBrowser Client Server cloudbrowser.cs.vt.edu Dept of CS Colloquium
CloudBrowser Architecture Web Browser Server-side JS Environment (node.js) JSDOM, Contextify Virtual Browser Forwards Events JS Web Application Client Engine Server Engine HTML CSS, Images Web SocketConnection Parses JSLibraries (jQuery, AngularJS) ObservesChanges Listens for Events AppliesUpdates Sends Updates DispatchesEvents Data Bindings JavaScriptApp-lication Code DeliversEvents node.jsLibraries Other Tiers Modifies DOM DOM DOM Dept of CS Colloquium
Implementation Implementation Platform Processing Client Events Synchronization Protocol Detecting Virtual Browser Changes JavaScript Execution
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
Processing Client Events • Block normal client-side event processing • Register capturing event listeners on those events • Call event.stopPropagation() • Call event.preventDefault()
Synchronization Protocol We establish RPC endpoints on the client and server.
Detecting Server-side DOM Updates varoldMethod=DOM.Node.appendChild; DOM.Node.appendChild=function(){ varrv=oldMethod.apply(this,arguments); browser.emit('DOMNodeInsertedIntoDocument',{ target:arguments[0], parent:this }); returnrv; }; • Changes detected using aspect-oriented method • Add wrapper methods (advice) around DOM manipulation methods. • Example:
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
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?
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
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
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)
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
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
DOM Conformance jQuery TestSuiteResults
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.
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
Scaling to Multiple Processes Front-end Server app1 Server (multi-process) Virtual Browser pipe Virtual Browser pipe ClientBrowser Virtual Browser pipe app2 Server (single-process) Virtual Browser Virtual Browser
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.
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
Future Work • CloudBrowser as a PaaS offering • Multi-process scaling improvements • Improved CloudBrowser API • Improved DOM conformance • Virtual browser management: • Persistence • Garbage collection
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
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 Dept of CS Colloquium