View
325
Download
1
Category
Preview:
Citation preview
Patterns and practices for buildingenterprise-scale HTML5 apps
Phil @leggetterphil@pusher.comphil@pusher.com
Join the conversation on Twitter: @DevWeek #DW2015
Patterns and practices that fed into the workflows and application architecture that was core to the
BladeRunnerJS toolkit.
–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.
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
Gmail & Caplin Trader• Large Single Page Apps (SPAs)
• Complex functionality
• Complex interactions
• User
• Technology
• Leave open all day
Who contributes to an app?• Front-end devs
• Back-end devs
• Designers
• QA
• Infrastructure and release engineers
• Technical authors
Maintainable?1. Massive codebase
2. Architecture
3. Contributor harmony
4. Promote quality
5. Productive developer experience
6. ^All complimentary
The Solution
“Write small, focused, modular parts, and progressively combine them into bigger things to make
your app”
@substack | @briantford
The Solutions
1. Components/Widgets/Modules
2. A Services Layer
3. MV*
4. Efficient Testing
5. Tools to Support Workflow
Features• Unaffected by breaking changes elsewhere
• Easy to find & change assets
• Can run in isolation
• Fast reload times
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
Services are a Contract/Protocol/Interfacehttps://www.youtube.com/watch?v=JjqKQ8ezwKQ
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’ );
Why use services?
• Features should not directly communicate
• Easily change implementation
• Implementations can be injected for different scenarios:
• Workbench / Test / App
Caplin Dev Practices• Multiple contributing teams
• SCRUM - 2 week iteration
• Continuous Integration & Delivery
• Build status displayed on screen
• A focus on Quality Software
~2009 Testing Requirements
• Cross-browser IE6+*, Firefox 3.5*+ & Chrome
• Class-level Unit Tests
• Application Acceptance Tests
* Remember this was 2009
Application ATs• Selenium Tests
• Selenium User-Extensions
• Actions, Accessors/Assertions & Locators
• VM infrastructure for CI
3
3. Launch browser + App
AT Process1
1. Pair Browser + Backend VM2
2. Reset & restart backend services
5
5. Record results
4
4. Execute ATs6
6. Reset backend services
8. Execute next test…
8
7
7. Restart/refresh browser
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
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
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
Need Proof?Our full suite Caplin Trader
testing time went from
>8 Hours
< 30 minutes
Much less for a single feature
Automation
• Define workflow & promote consistency
• Scaffolding
• Dev Server
• Builds/Bundling
• Tests
Compliance
Embrace Constraints
https://gettingreal.37signals.com/ch03_Embrace_Constraints.php
Customization
• Augment workflow
• Identify allowable change to workflow
• Automation commands
• Builds/Bundling
• Test Runner
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!
Thanks & Questions?
Phil @leggetter phil@pusher.com
Practical • Get USB sticks from me
• Or… go speak to the BladeRunnerJS team
Patterns and practices for buildingenterprise-scale HTML5 apps
Phil @leggetterphil@pusher.comphil@pusher.com
Join the conversation on Twitter: @DevWeek #DW2015
Recommended