How to Build Single Page HTML5 Apps that Scale

1,305 views

Published on

Developing large apps is difficult. Ensuring that code is consistent, well structured, tested, maintainable and has an architecture that encourages enhancement is essential. When it comes to large server-focused apps, solutions to this problem have been tried and tested.

But, how do you achieve this when building HTML5 single page apps?
In this talk we’ll cover the signs to watch out for as your HTML5 SPA grows and provide examples of some of the tooling types that can contribute-to as well as ease the growing pains. Finally, we’ll demonstrate how tooling can be used to support a set of conventions, practices and principles that enable a productive developer workflow where the first line of code is feature code, features can be developed in isolation, code conflicts are avoided by grouping assets by feature and features are composed into apps.

The demonstrations will use BladeRunnerJS, an open source developer toolkit written in Java, but the concepts are widely applicable.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,305
On SlideShare
0
From Embeds
0
Number of Embeds
84
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

How to Build Single Page HTML5 Apps that Scale

  1. 1. @leggetter#HTML5AtScale How to Build Single Page HTML5 Apps that Scale Phil Leggetter @leggetter Caplin Systems
  2. 2. @leggetter#HTML5AtScale bladerunnerjs.org OpenSource
  3. 3. What is a large-scale Single Page HTML5 App?
  4. 4. @leggetter#HTML5AtScale –Addy Osmani, Patterns For Large-Scale JavaScript Application Architecture In my view, large-scale JavaScript apps are non- trivial applications requiring significant developer effort to maintain, where most heavy lifting of data manipulation and display falls to the browser.
  5. 5. Large Codebase More functionality === More code
  6. 6. @leggetter#HTML5AtScale Caplin Trader • SDK: • ~1,000 JavaScript files • ~131,000 LoC • ~131 lines per file • ~650 test files • ~95,000 test LoC • Typical Apps: • ~425 JavaScript files • ~50,000 LoC • ~117 lines per file • ~200 test files • ~21,000 test LoC
  7. 7. Complexity
  8. 8. @leggetter#HTML5AtScale Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
  9. 9. Features: Change, Come & Go
  10. 10. Feature Progression
  11. 11. Contributors The Human Factor
  12. 12. @leggetter#HTML5AtScale Who contributes to an app? • Front-end devs • Back-end devs • Designers • QA • Infrastructure and release engineers • Technical authors • Multiple teams
  13. 13. @leggetter#HTML5AtScale Maintainable? 1. Massive codebase 2. Architecture 3. Contributor harmony 4. Promote quality 5. Productive developer experience 6. ^All complimentary
  14. 14. The Solutions 1. Components/Widgets/Modules/Features 2. A Services Layer 3. MV* 4. Efficient Testing 5. Tools to Support Workflow
  15. 15. @YourTwitterHandle#DVXFR14{session hashtag} @leggetter#HTML5AtScale Prove it!
  16. 16. Feature ==> Blade
  17. 17. Finding assets is hard
  18. 18. /assets /feature-name
  19. 19. Long App Reloads
  20. 20. Image of app partially workingWho Broke the App?
  21. 21. @leggetter#HTML5AtScale Features • Can run in isolation • Unaffected by breaking changes elsewhere • Fast reload times • Easy to find & change assets
  22. 22. Compose Components/Modules into Apps
  23. 23. @leggetter#HTML5AtScale Adding features to Apps
  24. 24. Services
  25. 25. @leggetter#HTML5AtScale What is a service? • Use services to access shared resources • In-app inter-component messaging • Persistence Service • RESTful Service • Realtime Service • Services are a Contract/Protocol/Interface
  26. 26. Setting & Getting Services • Use a unique identifier for each service i.e. a simple string • Register (code or config). Code example: ! • Get http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
  27. 27. @leggetter#HTML5AtScale Why use services? • Features should not directly communicate • Easily change implementation • Implementations can be injected for different scenarios: • Workbench / Test / App
  28. 28. Fake Services
  29. 29. Fake/Stub/Mock Services
  30. 30. Real Services
  31. 31. Efficient Testing (We’ll get to MV*)
  32. 32. @leggetter#HTML5AtScale ~2009 Testing Requirements • Cross-browser IE6+*, Firefox 3.5*+ & Chrome • Class-level Unit Tests • Application Acceptance Tests * Remember this was 2009
  33. 33. @leggetter#HTML5AtScale
  34. 34. @leggetter#HTML5AtScale Application ATs • Selenium Tests • Selenium User-Extensions • Actions, Accessors/Assertions & Locators • VM infrastructure for CI
  35. 35. @leggetter#HTML5AtScale AT Process 3 3. Launch browser + App 1 1. Pair Browser + Backend VM 2 2. Reset & restart backend services 5 5. Record results 4 4. Execute ATs 6 6. Reset backend services 8. Execute next test… 8 7 7. Restart/refresh browser
  36. 36. @leggetter#HTML5AtScale Test Results • ~1300 UTs • ~500 ATs • 50 VM infrastructure to run tests concurrently • 8 Hours • Test results highly unreliable • We could only run a full suite of tests once per day - at night
  37. 37. @leggetter#HTML5AtScale Inefficient Testing! • Resetting back end services is too slow • Lots of moving parts. Things can go wrong. • Services don’t start = app won’t work. Not code but environment failure. • We want to avoid IO • … and querying the DOM
  38. 38. Don’t Touch that DOM
  39. 39. MVVM
  40. 40. End-to-End Module Testing • Testing features in isolation • Change view model and assert against mocked Service • Inject fake service, make calls and assert View Model
  41. 41. Need Proof? Our full suite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature
  42. 42. Tooling & Developer Workflow Focus on Features
  43. 43. What tooling offers?
  44. 44. @leggetter#HTML5AtScale Automation • Define workflow & promote consistency • Scaffolding • Dev Server • Builds/Bundling • Tests
  45. 45. Intelligence
  46. 46. Compliance
  47. 47. @leggetter#HTML5AtScale Knowledge of Runtime Scenarios • Workbench (dev-mode) • Test • App
  48. 48. @leggetter#HTML5AtScale Dependency Analysis
  49. 49. @leggetter#HTML5AtScale Customisation • Augment workflow • Identify allowable change to workflow • Automation commands • Builds/Bundling • Test Runner
  50. 50. @YourTwitterHandle#DVXFR14{session hashtag} @leggetter#HTML5AtScale Proven!
  51. 51. @leggetter#HTML5AtScale Proven! 1. Massive codebase - features 2. Architecture - features, services & MVVM 3. Contributor harmony - separation of concerns; codebase structure, features & architecture 4. Promote quality - features, services & MVVM 5. Productive developer experience - tooling 6. ^All complimentary - Yep!
  52. 52. @leggetter#HTML5AtScale Thanks / Questions •Phil @leggetter •phil@leggetter.co.uk ! •BladeRunnerJS •@BladeRunnerJS •bladerunnerjs.org

×