Download as PDF, PPTX
Uploaded byPhil Leggetter
Patterns and practices for building enterprise-scale HTML5 apps
This document outlines patterns and practices for developing enterprise-scale HTML5 applications, focusing on modular architecture to manage complexity. It emphasizes the need for a structured approach with components, services, and efficient testing to enhance developer experience and maintainability. The presentation also discusses the evolution of testing practices and the importance of contributor harmony in large-scale projects.
Patterns and practices for building enterprise-scale HTML5 apps
- 1. Patterns and practicesfor 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.
- 4. Patterns and practicesthat fed into the workflows and application architecture that was core to the BladeRunnerJS toolkit.
- 6.
- 7. What is alarge-scale JavaScript app?
- 8. –Addy Osmani, PatternsFor 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.
- 14. Gmail & CaplinTrader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
- 15.
- 16.
- 17.
- 18. Who contributes toan 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.
- 25.
- 26. What Problems is thissolving?
- 27. Slice up theApp
- 28. Image of apppartially workingWho Broken the App?
- 29.
- 30.
- 31.
- 34. Features • Unaffected bybreaking changes elsewhere • Easy to find & change assets • Can run in isolation • Fast reload times
- 35.
- 36.
- 38. DEMO Add a Featureto an Aspect
- 39.
- 40. What is aservice? • 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 aContract/Protocol/Interface https://www.youtube.com/watch?v=JjqKQ8ezwKQ
- 46. Using Services • Usea 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.
- 48. Why use services? •Features should not directly communicate • Easily change implementation • Implementations can be injected for different scenarios: • Workbench / Test / App
- 49.
- 50.
- 51.
- 52. Efficient Testing (We’ll getto 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 • SeleniumTests • 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 • ~1300UTs • ~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! • Resettingback 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.
- 63.
- 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 fullsuite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature
- 67.
- 68. Tooling & Developer Workflow Focuson Features
- 70.
- 71. Automation • Define workflow& promote consistency • Scaffolding • Dev Server • Builds/Bundling • Tests
- 72.
- 73.
- 74. Knowledge of Runtime Scenarios •Workbench (dev-mode) • Test • App
- 75.
- 76.
- 77. Customization • Augment workflow •Identify allowable change to workflow • Automation commands • Builds/Bundling • Test Runner
- 78.
- 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 practicesfor building enterprise-scale HTML5 apps Phil @leggetter phil@pusher.com phil@pusher.com Join the conversation on Twitter: @DevWeek #DW2015