1 / 33

Building Web Applications For The Cloud

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 .

trent
Télécharger la présentation

Building Web Applications For The Cloud

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Building Web Applications For The Cloud Godmar Back Dept of CS Colloquium

  2. Do You Doodle? Dept of CS Colloquium

  3. Today’s Web Technology Landscape 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. Trygve M. H. Reenskaug(in 1979) Dept of CS Colloquium

  5. Presenting: The Meeting Scheduler • The brand-new Meeting Scheduler Application 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. Dept of CS Colloquium

  7. Reality Sets In Client Server 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… Dept of CS Colloquium

  9. Introducing CloudBrowser Client Server cloudbrowser.cs.vt.edu Dept of CS Colloquium

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

  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.

  15. 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:

  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

  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

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

  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

  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 Dept of CS Colloquium

More Related