Fed London - January 2015
•
1 gostou•857 visualizações
Building Front-End Web Apps that Scale talk from FED London at Yahoo! London. Concepts and practices that fed into the workflows and application architecture that was core to the BladeRunnerJS toolkit.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (9)
Semelhante a Fed London - January 2015
Semelhante a Fed London - January 2015 (20)
Mais de Phil Leggetter
Mais de Phil Leggetter (16)
Último
Último (20)
Fed London - January 2015
- 1. Building Front-End Web Apps that Scale
- 2. Phil @leggetter phil@pusher.com Head of Evangelism
- 3. Concepts and practices that fed into the workflows and application architecture that was core to the BladeRunnerJS toolkit.
- 5. What is a large-scale Front-End Web App?
- 6. Large Codebase More functionality === More code
- 7. 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
- 8. Complex
- 11. Gmail & Caplin Trader • Large Single Page Apps (SPAs) • Complex functionality • Complex interactions • User • Technology • Leave open all day
- 12. Long-Lived
- 15. Who contributes to an app? • Front-end devs • Back-end devs • Designers • QA / product owners / business analysts • Infrastructure and release engineers • Technical authors
- 16. Problems 1. Large codebase - Structure? 2. Complex interactions - Architecture? 3. Contributor harmony - Architecture & Developer Workflow? 4. Evolution of Features & Technology - Architecture? 5. Productive developer experience - Developer Workflow? 6. Promote Quality - All of the above
- 17. Slice up the App https://www.youtube.com/watch?v=vXjVFPosQHw
- 18. The Solution “Write small, focused, modular parts, and progressively combine them into bigger things to make your app” @substack | @briantford
- 19. The Solutions 1. Features/Components 2. A Services Layer 3. MV* 4. Efficient Testing 5. Tools to Support Workflow
- 20. Slice up the App
- 21. Slice up the App
- 23. What Problems is this solving?
- 24. Slice up the App
- 25. Image of app partially workingWho Broken the App?
- 26. Long App Reloads
- 27. Finding assets is hard
- 31. Features • Unaffected by breaking changes elsewhere • Easy to find & change assets • Can run in isolation • Fast reload times
- 34. Services
- 35. What is a service? • Use services to access shared resources • In-app inter-component messaging • Persistence Service • RESTful Service • Realtime Service
- 36. Services are a Contract/Protocol/Interface https://www.youtube.com/watch?v=JjqKQ8ezwKQ
- 37. Slice up the App
- 41. 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( ‘!chat.service’ );
- 42. Why use services? • Modular architecture • Features should not directly communicate • Easily change implementation • Implementations can be injected for different scenarios: • Workbench / Test / App
- 43. Workbench Tools
- 46. Efficient Testing (We’ll get to MV*)
- 48. Don’t Touch that DOM
- 49. MVVM
- 50. 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
- 52. Need Proof? Our full suite Caplin Trader testing time went from >8 Hours < 30 minutes Much less for a single feature http://j.mp/jsscale
- 53. Tooling & Developer Workflow Focus on Features Support Agile
- 55. Automation • Define workflow & promote consistency • Scaffolding • Development Server • Tests • Builds/Bundling
- 57. Intelligence • Code Dependency Analysis • Enforces rules • Knowledge of runtime scenarios & service configuration e.g. Workbench, Test, App/Aspect
- 58. Customization • Augment workflow • Identify allowable change to workflow • Automation commands • Builds/Bundling • Test Runner
- 59. Proven! 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
- 60. Phil @leggetter phil@pusher.com Head of Evangelism