Developing large apps is difficult. Ensuring that code is consistent, maintainable, testable and has an architecture that enables change is essential. As is ensuring that multiple developers – across multiple teams – can efficiently contribute to the same application. When it comes to large server-focused apps, solutions to some of these challenges have been tried and tested. But, how do you achieve this when building HTML5 single-page apps? In this session, Phil will cover the experiences his team have had when building HTML5 apps consisting of more than 250k lines of JavaScript (plus HTML templates, CSS, image, config etc) that are contributed to by multiple teams across multiple companies. He will highlight signs to watch out for as your HTML5 SPA grows, and a set of patterns and practices that help you avoid problems. He will also explain the simple yet powerful application architecture that their HTML5 apps have that is core to ensuring they scale. Finally, Phil will demonstrate how tooling can be used to support these patterns and practices, and enable a productive developer workflow where the first line of code is feature code, features can be developed and tested in isolation, code conflicts are avoided by grouping assets by feature, and features are composed into apps.

1. Patterns and practices for building
enterprise-scale HTML5 apps
Phil @leggetter
phil@pusher.com
phil@pusher.com
Join the conversation on Twitter: @DevWeek #DW2015

2. Agenda
• Talk & Demos
• Questions anytime*
• Q&A
• Practical

3. Phil @leggetter
phil@pusher.com
Chief Devangelist

4. Patterns and practices that fed into the workflows
and application architecture that was core to the
BladeRunnerJS toolkit.

6. bladerunnerjs.org
OpenSource

7. What is a large-scale
JavaScript app?

8. –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.

9. Large Codebase
More functionality === More code

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

11. Complexity

14. Gmail & Caplin Trader
• Large Single Page Apps (SPAs)
• Complex functionality
• Complex interactions
• User
• Technology
• Leave open all day

15. Features: Change,
Come & Go

16. Feature Progression

17. Contributors
The Human Factor

18. Who contributes to an app?
• Front-end devs
• Back-end devs
• Designers
• QA
• Infrastructure and release engineers
• Technical authors

19. Maintainable?
1. Massive codebase
2. Architecture
3. Contributor harmony
4. Promote quality
5. Productive developer experience
6. ^All complimentary

20. The Solution
“Write small, focused, modular
parts, and progressively combine
them into bigger things to make
your app”
@substack | @briantford

21. The Solutions
1. Components/Widgets/Modules
2. A Services Layer
3. MV*
4. Efficient Testing
5. Tools to Support Workflow

22. Prove it!

25. Feature ==> Blade

26. What Problems is
this solving?

27. Slice up the App

28. Image of app partially
workingWho Broken the
App?

29. Long App Reloads

30. Finding assets
is hard

31. /assets /feature-name

34. Features
• Unaffected by breaking changes elsewhere
• Easy to find & change assets
• Can run in isolation
• Fast reload times

35. DEMO
Create a Feature

36. Compose
Components/
Modules into Apps

38. DEMO
Add a Feature to an Aspect

39. Services

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

41. Services are a Contract/Protocol/Interface
https://www.youtube.com/watch?v=JjqKQ8ezwKQ

46. Using Services
• Use a unique identifier for each service
• Register (code or config). Code example:
• Get
http://martinfowler.com/articles/injection.html#ADynamicServiceLocator
var chatService = require( ‘service!chat.service’ );

47. DEMO
Using Services

48. Why use services?
• Features should not directly communicate
• Easily change implementation
• Implementations can be injected for different
scenarios:
• Workbench / Test / App

49. Fake Services

50. Fake/Stub/Mock Services

51. Real Services

52. Efficient Testing
(We’ll get to MV*)

53. Caplin Dev Practices
• Multiple contributing teams
• SCRUM - 2 week iteration
• Continuous Integration & Delivery
• Build status displayed on screen
• A focus on Quality Software

54. ~2009 Testing Requirements
• Cross-browser IE6+*, Firefox 3.5*+ & Chrome
• Class-level Unit Tests
• Application Acceptance Tests
* Remember this was 2009

56. Application ATs
• Selenium Tests
• Selenium User-Extensions
• Actions, Accessors/Assertions & Locators
• VM infrastructure for CI

57. 3
3. Launch browser + App
AT Process
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

58. Test Results
• ~1300 UTs
• ~500 ATs
• 10 pairs - VM infrastructure to parallelise tests
• 8 Hours
• We could only run a full suite of
tests once per day - at night
• Test results highly unreliable

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

61. Don’t Touch that DOM

63. MVVM

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

66. Need Proof?
Our full suite Caplin Trader
testing time went from
>8 Hours
< 30 minutes
Much less for a single
feature

67. http://j.mp/jsscale

68. Tooling & Developer
Workflow
Focus on Features

70. What tooling offers?

71. Automation
• Define workflow & promote consistency
• Scaffolding
• Dev Server
• Builds/Bundling
• Tests

72. Compliance
Embrace
Constraints
https://gettingreal.37signals.com/ch03_Embrace_Constraints.php

73. Intelligence

74. Knowledge of Runtime
Scenarios
• Workbench (dev-mode)
• Test
• App

75. Dependency Analysis

76. Dependency Analysis

77. Customization
• Augment workflow
• Identify allowable change to workflow
• Automation commands
• Builds/Bundling
• Test Runner

78. DEMO
Tooling

79. 1. Large codebase - By Feature: Component/Service
2. Complex interactions - Components & Services
3. Contributor harmony - Components, Services & Tooling
4. Evolution of Features & Technology - Components (e.g render
tech separation) & Services (common abstractions)
5. Productive developer experience - Tooling to support workflow &
concepts
6. Promote Quality - MVVM, Services and tooling. Facilitated by all of
the above
Proven!

80. Thanks & Questions?
Phil @leggetter
phil@pusher.com
Practical
• Get USB sticks from me
• Or… go speak to the BladeRunnerJS team

81. Patterns and practices for building
enterprise-scale HTML5 apps
Phil @leggetter
phil@pusher.com
phil@pusher.com
Join the conversation on Twitter: @DevWeek #DW2015